| Newsgroups |
gmane.comp.programming.scrum.general |
| Message-ID |
<CAJFr95Rc+ZGDLNmLYh0fnqjB5s2urWK7HHKZ=p5zi1de9z5Ozw@mail.gmail.com> |
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
On Tue, Nov 24, 2015 at 11:45 AM, Ron Jeffries [email protected]
[SCRUMDEVELOPMENT] <[email protected]> wrote:
>
>
> Charles,
>
> On Nov 24, 2015, at 2:09 PM, Charles Bradley - Professional Scrum Trainer
> and Coach [email protected] [SCRUMDEVELOPMENT] <
> [email protected]> 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 Jeffries
> ronjeffries.com
> Don't ignore your dreams; don't work too much; say what you think;
> cultivate friendships; be happy. -- Paul Graham
>
>
>