Wednesday, January 12, 2011

What does “Done” mean?

It starts with a team conversation...

One of my favorite team conversations that generated by the Scrum framework is one that occurs at the beginning of a Scrum project.  It’s the team discussion and subsequent agreement of what the word “Done” means.

A Scrum Team is supposed to produce potentially shippable code at the end of every Sprint.  This means that any stories (requirements) that the team commits to must be full implemented, documented, tested, etc within the time-boxed Sprint.  The stories must be DONE. Done can and often is defined differently by each team.  Minimally, Done means that the story committed to is coded and fully tested.  A story really can’t be potentially shippable if it isn’t coded and tested.  

Done is demonstrated during the Sprint Review, where working code is demonstrated the business owners and everyone else in attendance.   A story isn’t complete unless it satisfies the definition of “done”.  In fact, Scrum will not credit the team with story points unless a story is, in fact, “done” (and accepted by the Product Owner).  

Each Pilot team that I observed went through similar discussions about “done”.  Because Scrum was new to the teams, the initial definition of “Done” was a bit loose:  there was general agreement that a story was “Done” if it was coded and tested.    Over the course of the first Sprint Planning and the start of the Sprint 1, it often became apparent how loose that definition of Done actually was.  

The Product Owner and Team conversation for story acceptance criteria was one of the main catalysts for Done refinement.   As each member of the cross-functional team discussed the stories they were committing to, it was quickly realized that the initial definition of done left many questions unanswered.  Product areas such as documentation (what kind? what level?), training (again, what kind?), automated tests (how much should be automated? what platforms should be tested? what web browser? what about performance testing?) and bugs (should all be fixed?  just blockers? more than just blockers?) all had questions that needed answers.  

Over the period of a month or so, the teams each refined the meaning of Done.  The process of discussing, debating, and ultimately answering these questions helped the group grow into a high performance team.  This was very important to the success of the effort, as with Scrum the commitment to delivering a story is a team commitment, rather than an individual one.

A Great Habit

I think most would agree that it’s great to get in the habit of fully completing work, versus completing 80% of the work and leaving the remaining 20% for some time “later”, during the release end-game, or perhaps never (thereby wasting effort).  With Scrum, producing done work is essential to the process. In the pilots, I’ve noticed a tendency for teams to commit to too many story points during a Sprint, ultimately leaving one or two stories partially finished, though the team put in often heroic effort to meet the original commitment.  The unfinished stories were fortunately completed in the next sprint, but the fact that they were not complete often defeated the “potential” from the potentially shippable product.   One way to deal with this is for the team to sequentially complete stories within the sprint, never starting a new story until the current story is Done.  This isn’t always practical, or efficient, but the team should be aware of the story bleed and velocity drag that partially implemented stories create.  Alternately, it is perhaps better to commit to fewer story points per sprint and fill in any capacity with product maintenance or backlog grooming or architectural spikes.    These are team decisions that can be considered during Sprint Planning or during the Sprint Retrospective.


For me, the concept of Done is the key foundational principal that  makes Scrum agile.  At the end of a Sprint all stories are fully completed, thus potentially shippable.  This fact, coupled with a short development iteration, offers the business frequent predictable time windows in which to re-prioritize work or introducing completely new requirements.  Scrum allows an organization frequent opportunities to, in contemporary terms,  pivot.  Easily and readily shifting priorities with minimal impact to productivity is one of the primary mechanisms through which an engineering organization gains agility.

No comments:

Post a Comment