Re: [scrumdevelopment] Small team w multiple projects - tales from the voyage
- Bill Wake wrote:
> The other place I find people get jammed up is understandingI have an exercise that I always like doing with teams to get
> just how done "done" is intended to be (what it means to be
> "shippable" at the end of each sprint). People tend to forget
> testing, documentation, packaging, etc. and then find that
> ignoring these things didn't make them go away:) - and that
> they still have to happen before deployment.
them to define and agree to what "done" means.
I put up 3 big Post-its on the wall, and label them "Task,"
"Story" and "Sprint." I start at the Task one and ask them
"If I said I was 'done' with a task, what would you expect
that I would have done?" Same for story. We then discuss
all the things that we should be doing in order to be really
done with these things. The discussion that results is
usually really interesting, and I almost always find that the
team members have different views and expectations of done
in their current process.
For example, for a task we have things like code written and
compiles, database scripts updated, unit tests pass, things
are checked in and the team's build doesn't break, etc. For
a story we have things like acceptance tests pass, the Product
Owner has taken a look, help files updated, etc.
After a bit, I then ask "If I told you we had to roll into
production at the end of this next sprint, what else would we
need?" I usually get some horrified looks, but we add more
things to the list. This is where we get some things for the
Sprint chart, such as performance tests, release notes, etc.
that they may feel they would do once for the sprint.
Sometimes, they feel they can not get everything done for a
production release in a sprint, even if they use a longer
sprint like 30 days. In that case, we may make a 4th chart
for "Release" and those things would become items for that
last sprint before a release.
After we've discussed and agreed to these lists, I get them
to step back and consider that we need to make sure we account
for all this work in our sprint, otherwise we're just building
up "debt" that we have to pay off eventually, usually with
some pain involved. The room often gets pretty quiet at this
point as they realize what it all means.
I also will revisit this list after a couple of sprints and
use it as a centerpiece for discussing how we can improve our
process. We discuss items we missed and especially how we
can get the items to move further and further to the left
This exercise can take somewhere around 30 minutes or longer
to go through, but I highly recommend that every team does
this before they try to do any estimating or plan a sprint.
Paul Hodgetts -- CEO, Coach, Trainer, Consultant
Agile Logic -- www.agilelogic.com
Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP
Complete solutions for adopting agile processes, Scrum and XP.