Keeping a Good Agile Estimation Practice

As part of our Scrum practice at vianet, we spent time as a team tending to the Product Backlog. We played planning poker and kept all our stories sized. We knew the entire size of the Product Backlog. Every Sprint we looked ahead and refined some User Stories.

Our velocity was stable and we could predict what User Stories would fit in a Sprint. The total size of the Product Backlog and the number of Sprints left projected that we would not hit the date promised to the customer.

Verifying the Estimates

The Product Owner started to question our estimates. He neither questioned the technique itself nor the merits of relatively sizing items, just the numbers we produced from this estimation technique.

We decided to spend a day with the Product Owner looking over the backlog. We looked at some of the work we’d finished to help calibrate sizes, and triangulated it with the items not yet started. Some of our User Story estimates changed. We sliced some of our User Stories thinner and even removed a couple. The Product Owner was convinced that our estimates were sound.

When we finished and totaled up the points, it was nearly the same as the beginning number. We learned that keeping the backlog sized is priceless and that reassigning points is useless. The total size of the Product Backlog had not moved a significant amount from all of our work, although we now were intimately familiar with it.

Time for a Talk

This didn’t help the fact that we all recognized that we needed to have a tough discussion with the customer.  We couldn’t deliver on the date we promised with the features they wanted.Икони на светци