Monday, June 21, 2010

Should Developers Buffer Estimates?

We use a typical Agile methodology during software development. During Iteration Planning engineers want to buffer/pad their estimates. Their logic is that something may come up! This leads to:
  • Obviously, bloated estimates.
  • Bloated estimates even on predictable tasks.
  • No visibility to what type of issues we tend to miss out while estimating (as everything is lost in the buffers)
  • Work expands to fill the time we have.
  • Reduction/Destruction of trust with the Product Owner.

My questions against this is How do you know that the buffer you are keeping is adequate for “something may come up? How can you estimate an unknown? My recommendation is to base the estimates on the current knoweldge of tasks and its delivery with Quality. For other things that crop up we manage as and when we see the unknown.

If an unknown does crop up the “rule of the book” is that the Product Owner should be considerate enough to drop the low priority user stories. But the reality is that many of the Product Owners do not agree. The role of the Scrum Master at this time is to convince the PO or move the equivalent tasks to the next Iteration. This does not come easy to non-Agile PO practitioners but is the only way to prevent drop in Quality of tasks or slippage of schedules.

One way to make this scope adjustment easy was used in one of my previous organizations by marking the features as “Must Have”, “Should Have”, “Nice to Have”. My issue with this is that this again leads to “Work expands to Fill In the Time”. The devlopment team ends up consuming most of the time in “Must Haves” and scope adjustment needs to be done there.

The retrospectives at the end of Iteration are the right time to relook closely at those tasks where we did a bad estimate / found unknowns to find what type of issues/work we tend to overlook. This is the learning which if taken forward helps the team to do better estimates as well as points to development/learning areas for a team.

In a nutshell bufferring brings opaqueness to the development process and needs to be avoided.

As a side note one of my engineers came up with – buffering is also done because it is driven by the year end Appraisal process which may have heavy weightage for “Timeliness of tasks”. The fix for that lies both with the engineer and his manager. The manager and engineer should collaborate to see where the estimation errors come from and thus over a one year appraisal cycle we should see statistical averaging helping in some tasks finished ahead of schedule and a few late but overall project timelines being met.

No comments:

Post a Comment