Geese In Formation - Coon Rapids, MN
In a previous post (Two Phase Commits in Agile) I introduced the idea of two levels of estimation – coarse story points that are suitable for managing the funnel of work into the teams and another level of estimation within the iteration designed to build buy-in within the team for the iteration itself. Jeff Whiteside, one of our feature team leads, has been particularly innovative in this respect, so I asked him to share his thoughts and methods with us. Here goes – thanks Jeff!
———————————————————————
Students are taught to fly planes relying only on their instrument panel. They wear hoods or glasses limiting their vision to see only their controls. They must learn to trust the controls and their own instincts. Of course the instructor is always there to help if things get out of control. Now imagine if the controls were unavailable as well and all you had to rely on is the instructor reassuring you that everything was fine.
As I began leading my development team in Belarus, I found my role somewhat analogous to the student. As our two-week iterations progressed, I would get frequent status updates from my team, usually, very positive, hailing the great progress and always promising to complete features on-time. Yet, iteration after iteration, we failed to deliver. The code was usually complete; however, the testing was not.
I challenged my team to find a solution for this problem. They determined that the story estimates we provided them were not accurate. After failed attempts to involve them in story estimation, I asked them to estimate the stories. The story estimates we provided were in abstract story points. The estimates they would provide would be in person hours including both developers and testers. The estimations would be done during iteration planning. Now we had always done iteration planning, but I could never be sure what was really occurring. I got the sense that they spent a few minutes looking at the stories and then jumped back into code to finish up the work they didn’t finish in the previous iteration. I wanted them to really analyze the stories and personally and publicly commit to completing each. As a bonus they would be allowed to reject or split stories they could not commit to. Of course it would be the product owners prerogative as to which stories were removed.
In order to get accurate estimates, the team needed to break down each story into actionable tasks and estimate each. This process of breaking down tasks forced them to thoroughly analyze the requirements and get immediate clarification for anything unclear. Since the tester was also responsible for estimating their effort, they were more engaged in the task breakdown so they better understood the stories. The engineers were also encouraged to design and prototype any complex stories during iteration planning, improving estimates. This process usually took between two and four hours. For complex stories with a lot of design or prototyping, it could take a full day. I was okay with this as long as the process produced stories with actionable tasks and reasonable estimates.
Each day the team re-estimated each story determining how much work was remaining. This was plotted on a graph against the number of hours available in each day. The result is a burndown chart that visually shows the teams progress against the expected progress, clearly indicating if the team is on schedule or falling behind. If the actual was on a slope equal or greater than the baseline we were on track, but if the actual began to creep above the baseline we were falling behind.
Example Iteration Burndown
So how did all this help us? First, since the team was publicly committing to completing the work, a new sense of urgency surfaced. They also took more ownership of the stories. Second, since we were estimating in person hours, we could better predict the right amount of stories to add to the iteration by comparing the estimate to team capacity. This normalized our velocity and improved the teams rhythm. Third, it provided a immediate visual feedback allowing us to adjust, refocus, or renegotiate with the product owner. These changes made dramatic improvements in how the team functioned and its effectiveness and I new feel less like I am flying blind.
- Jeff Whiteside
