:::: MENU ::::
Posts tagged with: scrum

What is the definition of Done?

 Scott Hanselman has a pretty interesting discussion with Scrum co-creator Ken Schwaber around the concept of when is a story Done.


Ken raising some interesting points, most notable that a well defined concept of Done, understood by all members of the project is a cornerstone of a good scrum process.  Without it, you can guarentee that you are building up technical debt; and your software won’t be in a releasable state once you have “Done” all the features, which kind of defeats the point of release planning!

So, what is your definition of done?

  • All acceptance cases / test scenarios pass?
  • Unit tests pass?
  • Performance tests pass?
  • Customers have used and approved the feature?

Story points = Complexity points / relative size

One of the ideas many people seem to struggle with in Agile projects is that of Story Points.

In an agile project, the time to implement a story (a feature), is deliberately estimated in a weird unit called story points, rather than in number of hours / days.

The most important thing to remember is that story points do NOT equal units of time.  Initially you will naturally find yourself trying to convert story points to days, or estimating in days or hours, and then trying to convert that to story points.

RESIST this temptation!  There is a method behind the madness.

  • Research has shown that people are better at estimating relative sizes (A – C is twice as far as A – B, Basket X is about 1/3 the weight of Basket Y) than coming up with absolute estimates (A to B is 15km, Basket X is 7.5kg)
  • Days are a very subjective unit of measure.  Depending on other commitments, your ideal days are very different from mine.
  • Estimating relative size is much quicker; and you need less information to get started (you don’t actually have to know how long anything will actually take, just the relative comparisons between different stories)

With a new project its impossible to know how quickly features will be produced.  There are just too many variables – learning of the domain & toolset, agreement within the team, stabilizing of work patterns.

What you do is complete a couple of iterations, and then measure how many story points you delivered on average.  This then becomes your velocity, which you can use to derive an estimated completion range based on the story points.

Note that with this technique your story points are still valid; as they are just measures of relative size/complexity.  The only time you really need to re-estimate story points is when you got the relative size of a story wrong – perhaps it turns out to be much easier to send emails than you thought, or much harder to draw graphs.