Decade's founder leaves for Europe tomorrow—and today I received a special package from Europe—Denmark to be precise. The package contained five very special decks of cards—for playing a very special round of Poker. It just so happens that the development team will begin playing poker shortly after Kevin boards his plane.
Every thirty days, the Development Team completes one sprint and prepares for another. Thursday morning, we will hold a requirements hand-off meeting. In that session, the Product Owner—CTO Darryl Booth—will present the team with the prioritized EnvisionConnect product backlog. During that session, the team ask questions and seek clarification on any requirements that may seem vague. The goal is to get the bulk of the information needed in order to decide what functionality can be delivered by the end of the sprint.
Following the hand-off session, the official July Sprint Planning Meeting will begin. In this meeting, the team will ask questions of each other—and potentially anyone else they can reach by phone—in order to decide what work they will commit to for that sprint.
Once this is done, iteration planning usually begins. In this stage, we break everything down into tasks—each ranging from two to eighteen hours. This information is then entered into Team Foundation Server in order to feed our Sprint Burn-down Chart.
The Iteration Planning step is not inherent in Scrum. It has proven necessary for us, as our requirements team delivers requirements in completed Use Case form. The Use Case defines the final product. The team has to map and define iterations from the expected final delivery.
Should iteration planning occur before the sprint planning meeting? We have tried it both ways—with different levels of success on either side.
The real problem we've had—and this will sound familiar to you—is estimates. One developers twelve hours is often another developer's four hours, and sometimes one developer's week is another developer's month.
I have read Microsoft Press' Software Estimation: Demystifying the Black Art cover to cover—it was very little help, aside from convincing me that we are not alone.
We've tried T-Shirt sizes, Wisdom of the Crowds, and every other passing estimation fad we've come across. I was beginning to believe that paper, rock, scissors would be just as accurate.
In the end, we have found success—as recent burn-down charts have shown—but as with any other process, we are always looking for improvement.
This sprint, we will try the Agile-praised Planning Poker for the first time, and I am very excited about it. Three weeks ago, I ordered five printed decks from Nordija in Denmark—that was yesterday's package—and tomorrow, we deal 'em.
I'll let you know how well it works for us.
2 comments:
Should iteration planning occur before the sprint planning meeting? We have tried it both ways—with different levels of success on either side.
Iteration Planning means that you are taking what you committed to doing during sprint planning and dividing it into iterations. However, we also experiment occasionally with some pre-planning in order to have a better idea of scope before sprint planning begins
Post a Comment