[SCRUMDEVELOPMENT] Decomposing only minimal work in Sprint Planning

[Charles Bradley - Professional Scrum Trainer and Coach [e-mail] [SCRUMDEVELOPMENT]]

Hello fellow ScrumDev-ers,
As I understand it, the Scrum Guide requires that the Scrum Team decompose the work(Sprint Backlog) for at least the first couple of days of the Sprint.  I think every Scrum team I've ever encountered goes ahead and attempts to decompose the work for the entire Sprint inside of Sprint Planning (leaving room/flexibility for emergence of course).

Have any of you run across real life teams that decompose only the first couple of days worth of work in Sprint Planning?  If so, in what contexts did you find this beneficial?  Also, what was the team's main reason(s) for doing it this way?-------
Charles Bradley
Chief Executive Officer
Professional Scrum Trainer
http://AgileSoftwareTraining.com
Agile Software - Training, Consulting, Coaching

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Charles,

Have any of you run across real life teams that decompose only the first couple of days worth of work in Sprint Planning? If so, in what contexts did you find this beneficial? Also, what was the team's main reason(s) for doing it this way?

I’ve encountered teams that don’t really decompose at all, instead just talking about how they’ll likely do things.

The advantages of decomposing little include: less work; fewer mistakes; less commitment to a plan made at the worst possible moment; more chance for the team to swarm; more emphasis on what’s most important i.e. first.

Ron Jeffries
ronjeffries.com <http://ronjeffries.com/>Don't ignore your dreams; don't work too much; say what you think; cultivate friendships; be happy. -- Paul Graham

[Charles Bradley - Professional Scrum Trainer and Coach [e-mail] [SCRUMDEVELOPMENT]]

Thanks Ron.
Are these teams that start out with very small items to begin with?  (Sort of like micro-stories pattern -- most stories 3 days or less?)
-------Charles Bradley
Chief Executive Officer
Professional Scrum Trainer
http://AgileSoftwareTraining.com
Agile Software - Training, Consulting, Coaching

From: "Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: ***@yahoogroups.com
Sent: Tuesday, November 24, 2015 12:45 PM
Subject: Re: [SCRUMDEVELOPMENT] Decomposing only minimal work in Sprint Planning

#yiv1695890846 #yiv1695890846 -- #yiv1695890846 .yiv1695890846ygrp-photo-title{clear:both;font-size:smaller;height:15px;overflow:hidden;text-align:center;width:75px;}#yiv1695890846 div.yiv1695890846ygrp-photo{background-position:center;background-repeat:no-repeat;background-color:white;border:1px solid black;height:62px;width:62px;}#yiv1695890846 div.yiv1695890846photo-title a, #yiv1695890846 div.yiv1695890846photo-title a:active, #yiv1695890846 div.yiv1695890846photo-title a:hover, #yiv1695890846 div.yiv1695890846photo-title a:visited {text-decoration:none;}#yiv1695890846 div.yiv1695890846attach-table div.yiv1695890846attach-row {clear:both;}#yiv1695890846 div.yiv1695890846attach-table div.yiv1695890846attach-row div {float:left;}#yiv1695890846 p {clear:both;padding:15px 0 3px 0;overflow:hidden;}#yiv1695890846 div.yiv1695890846ygrp-file {width:30px;}#yiv1695890846 div.yiv1695890846attach-table div.yiv1695890846attach-row div div a {text-decoration:none;}#yiv1695890846 div.yiv1695890846attach-table div.yiv1695890846attach-row div div span {font-weight:normal;}#yiv1695890846 div.yiv1695890846ygrp-file-title {font-weight:bold;}#yiv1695890846 #yiv1695890846

Charles,

On Nov 24, 2015, at 2:09 PM, Charles Bradley - Professional Scrum Trainer and Coach chuck-***@emailchuck.com [SCRUMDEVELOPMENT] <***@yahoogroups.com> wrote:
Have any of you run across real life teams that decompose only the first couple of days worth of work in Sprint Planning?  If so, in what contexts did you find this beneficial?  Also, what was the team's main reason(s) for doing it this way?

I’ve encountered teams that don’t really decompose at all, instead just talking about how they’ll likely do things.
The advantages of decomposing little include: less work; fewer mistakes; less commitment to a plan made at the worst possible moment; more chance for the team to swarm; more emphasis on what’s most important i.e. first.

Ron Jeffriesronjeffries.comDon't ignore your dreams; don't work too much; say what you think; cultivate friendships; be happy. -- Paul Graham

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Not necc start out. But no team leaves my hands without knowing to do that.

Are these teams that start out with very small items to begin with? (Sort of like micro-stories pattern -- most stories 3 days or less?)

Ron Jeffries
ronjeffries.com <http://ronjeffries.com/>
Perfectionism is the voice of the oppressor -- Anne Lamott

[Michael K Spayd [e-mail] [SCRUMDEVELOPMENT]]

Hello Charles,
Well, since Ron has replied, I better add my 2 cents (and build on his) :-).

I often see ScrumMasters misunderstand the Scrum Guide and think that teams
must do TASKing. Clearly, that is not what it says. Without looking
specifically, my strong recollection is that it says something to the
effect that the team has a plan for how they will do their work. This is,
in my view, in keeping with the transparency and autonomy agreement
implicit between management and Scrum teams. In short: teams agree to make
their work transparent to management in exchange for management staying the
hell out of the team's bubble during a sprint (autonomy). "Having some kind
of plan" is part of the balance - I can see you're not flying by the seat
of your pants here, but you also don't have to have a highly structured
plan, or one that I as manager even agree with.

Building on what Ron says, which I like, I would say I prefer a team talk
through some possible approaches, some key assumptions they may be making
(especially ones that could really mess up the plan if not true), and maybe
some key questions to be answered in the doing of the work. Not a long
exhaustive (and exhausting) planning process, but a top of the mind bullet
list on a flip chart for each story. That would inspire a hell of a lot
more confidence in me as a manager than some of the worthless "going
through the motions" task lists I've seen.

I hope that is on point.

Regards,
Michael

Post by Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]
Charles,
On Nov 24, 2015, at 2:09 PM, Charles Bradley - Professional Scrum Trainer
Have any of you run across real life teams that decompose *only* the
first couple of days worth of work in Sprint Planning? If so, in what
contexts did you find this beneficial? Also, what was the team's main
reason(s) for doing it this way?
I’ve encountered teams that don’t really decompose at all, instead just
talking about how they’ll likely do things.
The advantages of decomposing little include: less work; fewer mistakes;
less commitment to a plan made at the worst possible moment; more chance
for the team to swarm; more emphasis on what’s most important i.e. first.
Ron Jeffries
ronjeffries.com
Don't ignore your dreams; don't work too much; say what you think;
cultivate friendships; be happy. -- Paul Graham

[Adam Sroka [e-mail] [SCRUMDEVELOPMENT]]

Rather than decomposing I like to make a story map with the whole team,
identify the walking skeleton, and start with that. At some point I will
probably ask the team to throw away the story map and make a new one,
because we will have learned stuff.

Other than that I agree with the sentiment to keep the backlog as small as
possible with just a few days worth of really small, high priority stories.
I think the Lean folks do a good job of explaining why making a “complete”
backlog is wasteful. So, I won’t repeat that here.

On Tue, Nov 24, 2015 at 11:09 AM, Charles Bradley - Professional Scrum

Post by Charles Bradley - Professional Scrum Trainer and Coach chuck-***@emailchuck.com [SCRUMDEVELOPMENT]
Hello fellow ScrumDev-ers,
As I understand it, the Scrum Guide requires that the Scrum Team decompose
the work(Sprint Backlog) for *at least* the first couple of days of the
Sprint. I think every Scrum team I've ever encountered goes ahead and
attempts to decompose the work for the entire Sprint inside of Sprint
Planning (leaving room/flexibility for emergence of course).
Have any of you run across real life teams that decompose *only* the
first couple of days worth of work in Sprint Planning? If so, in what
contexts did you find this beneficial? Also, what was the team's main
reason(s) for doing it this way?
-------
Charles Bradley
Chief Executive Officer
Professional Scrum Trainer
http://AgileSoftwareTraining.com <http://agilesoftwaretraining.com/>
Agile Software - Training, Consulting, Coaching

[Eric Gunnerson [e-mail] [SCRUMDEVELOPMENT]]

It does depend on what you mean by “decompose”..

I’ve been on a team where we took our stories and decomposed them into parallelizable vertical slices as part of our planning, but we didn’t do any technical decomposition. We had found that doing technical decomposition in planning gave poor results compared to what we got with pairs, so we stopped doing it.

From: ***@yahoogroups.com [mailto:***@yahoogroups.com]
Sent: Tuesday, November 24, 2015 11:10 AM
To: yahoogroups <***@yahoogroups.com>
Subject: [SCRUMDEVELOPMENT] Decomposing only minimal work in Sprint Planning


Hello fellow ScrumDev-ers,

As I understand it, the Scrum Guide requires that the Scrum Team decompose the work(Sprint Backlog) for at least the first couple of days of the Sprint. I think every Scrum team I've ever encountered goes ahead and attempts to decompose the work for the entire Sprint inside of Sprint Planning (leaving room/flexibility for emergence of course).

Have any of you run across real life teams that decompose only the first couple of days worth of work in Sprint Planning? If so, in what contexts did you find this beneficial? Also, what was the team's main reason(s) for doing it this way?
-------
Charles Bradley
Chief Executive Officer
Professional Scrum Trainer
http://AgileSoftwareTraining.com<http://agilesoftwaretraining.com/>
Agile Software - Training, Consulting, Coaching