Thursday 15 March 2012

Trying a different relative estimation approach

At TagMan, we use frameworks that facilitate the Agile mindset as much as possible. Some teams are currently using Scrum, while others are taking a more Kanban-like pull/flow approach. We are still learning both, and constantly look at how we can understand the outcomes of the frameworks, so that we can make them effective in the context of our particular environment.

One of the teams planning their next sprint with their Product Owner
Estimation in general is a double-edged sword. When you have a system that starts to flow well, it actually can become a form of waste. However, while we are still learning it's a useful means to allow us to understand our throughput each development sprint, and to better understand differences in complexity. From a scheduling point of view the main benefit of estimation is really just to allow you to plan releases effectively when you are using an iterative approach.

We have recently adapted our estimation approach to see if it makes the planning process more effective and enjoyable, and wanted to share our experiences with you!

One of the key things to take on board when approaching estimation in an Agile environment, is to separate time from effort. For a lot of teams, this is facilitated in the units by which they estimate. A lot of teams (like ourselves) use the concept of "Story Points"  (User Stories are self-contained valuable small features) to give an idea of "size" for a story.

These story points are numbered in a modified Fibonacci sequence, so that there is an increasingly large gap between numbers, the bigger you get. We do this to represent the fact that something small will be much more defined, so comparing it to something else of same or similar size is therefore easier, and can be more accurate. The bigger something is, the more unknown complexity will be found inside, so we need to account for that hidden and unknown effort. Once you know your throughput within a given time frame, you can then accurately forecast timeframes for scheduling.

Now, down to the estimation itself. When we estimate, we need to account for:
  • past experience, 
  • expert knowledge and 
  • disaggregation (which is relevant because we are never 100% sure who will work on a particular task).
Due to these factors estimations need to be made by as much of the team as possible together (not always practical) and certainly not by anyone outside of the team: They are not doing the work!

One technique widely adopted is "Planning Poker" which allows teams to account for the three factors above in a relatively egalitarian environment. I've personally used it with many teams, but at TagMan the game seems a little contrived. We've also tried silent grouping estimation - this didn't seem to work the first time we tried it, but recently we revisited the concept, with some alterations:

Instead of putting down the Story Points in isolation as the column headers, we grabbed a load of stories from the last sprint, so that we had one for each size. We used these as the column headers. We also didn't mandate silence, as at our current team maturity we felt it was more useful to place the stories together and discuss where we felt it was needed. This actually increased our overall domain knowledge whilst facilitating disaggregation.

We also placed the columns at physically different distances from each other as a visual cue of the difference in size. This achieved three things:
  1. We were able to compare to the old stories initially, to allow continuity of estimation sizes
  2. We really stopped to think before we automatically placed a story in a large estimate column, this ensured better accuracy and questioned what really was unknown. We found this effective to avoid estimate inflation.
  3. Once more stories were on the board it made triangulation of estimates that much easier, which made the process much quicker than poker sessions.

We managed to get through a larger amount of stories than normal, and were able to approach the stories more effectively, given that we were largely on the same page! If you try the silent grouping or this revised version yourself, then we'd love to hear about how you got on with it.

Dan W

No comments:

Post a Comment