scruminfo.com

I once observed a practice where story cards were only estimated based on the development effort. This is problematic as it has one specific focus and not looking at the total work that needs to be completed for a story to be moved into done. Product development is not just about writing code.

Common symptoms that are evident when only development estimates are used are:

1. A large number of stories sitting in testing at the end of the sprint or iteration.
2. Planning goes haywire
3. Team has to really push things through greater effort to meet release plan and get stories into done, this is especially common in the last iteration before a release. I see this as an awesome rhythmic in-balancer.

To simplify the essence of what I am trying to get across is:

A story card with a size of 1, may only require a quick code change and a simple unit test re-factor, but the acceptance testing that the change caused could be in the magnitude of 4, so not taking this into account the story is planned as a 1, which is not accurate.

The group then realised that this was problematic and decided to include testing in the estimate, but an even bigger problem emerged, the testing estimate was to be independent of development. The result was that a story could have a test estimate of say 2 and a development estimate of 4.

Observing this led me to ask myself how on earth can there be a consistent approach to planning for release and iterations.

For a story with a testing of 2 and development estimate of 4:

1. Do I plan treating the card as 2 points?
2. Do I plan treating the card as 4 points?
3. Do I plan treating the card as a summation of 6 points?

This observation highlighted an even bigger problem that existed. A team that is separated and an organisational culture that has defined boundaries between testing and development. An agile team is a cross-functional united group that has no clear delineation between testers and developers, it works as a single entity that delivers value.

I cannot emphasise the importance of a single estimate for a user story. Lets take the scenario above and see how it should work.

This estimation scale is for demonstrative purposes only:

Estimation scale: 1 (Very Small) 2 ( Small) 3 (Medium) 4 (Large) 5 (Too big)

Team members with development skills think that the story is pretty small and there is not much complexity involved, team members with testing skills have a feeling that this is going to be pretty big and complex as a number of acceptance tests need to be changed, one of the tests is not automated. There are also some UI tests that need to be run.

The team discusses this for a short while and comes to an agreement that 4 points is more realistic to get this story from Not Done to Done. The card is allocated a single estimate of 4. When it comes to planning we now have taken into account all the work to get the story done.

Filed under: Scrum Articles, Techniques