Original Estimate. Remaining Work. Completed Work.

These have been the three most underutilized and ignored fields in our TFS template for over two years. We did an entire application re-write with three major release milestones, multiple integration points, and multiple small maintenance releases hardly acknowledging these fields. What little estimation data the project manager received was from one person on the team. Actual information was never fed back in. Estimations were broken. It was increasingly difficult for the project manager to reliably communicate with the business what the team could accomplish at what time. This was the biggest pain point we could identify.

Our bottom up approach to Agile implementation started here. As long as upper management received time based estimates on features for Enterprise planning purposes they were not especially concerned with where they came from. They cared only for how accurate we felt they were and how accurate they ended up being. That mindset allows us to change our estimation methods with little fear of interference. This is likely a common state for a project team to be in.

Project estimates have always been given in hours. When given a requirement the team lead would think of the tasks needed to fill it, who would probably have the task assigned to them, and how long he felt it would take them to finish. This is the information that was then passed back in as an estimate. It was not quite as bad as it sounds. The business analysts and project manager were generally far enough ahead of the business that these numbers were still useful to upper management when they got them. For the project in maintenance mode this worked well. For the new project launching it was not working very well at all.

The problem was not so much on getting a number to management as it was in the number being a good useful one going forward. By the time the work was approved the environment had changed. Sometimes a different person would do the tasks. Only actual coding time was being considered for the estimates. All of this combined to leave little business value in the numbers.

A new way of doing estimates was in order. Utilizing a combination of my training,, research, reading, and our project managers prior experience we had to come up with something new. The primary requirements were to involve the whole team and provide more useful numbers for the project planning group. The best place to start seemed to be planning poker. The idea was to bring the team together and get each person to give their idea of an estimate without relying on the team lead.

Two things. Planning poker is explained in more detail here (pt 1) and here (pt 2). Agile Estimation and Planning by Mike Cohn is a book that I spent time reading before this point in our transformation. I reviewed it here.

I created cards for story points and cards for hours. Both sets used a modified Fibonacci sequence of: 0,1,2,3,5,8,13,20,40,100. For story points I backed the cards with boxes, pallets, and even a truck of pallets to help show the size differences represented by the numbers. The cards for hours had nothing but numbers.

I prepared the project manager ahead of time with how it would work. It did not take long to get her on board, but she was a little leery of story points. Her concern was that upper management was looking for time estimates. I assured her that when we had a few iterations under our belts and could show velocity it would work out just fine.

The meeting started with an explanation of story points. What they were was easy, why we use them was a little harder, but everybody understood the concept in short order. I made sure to explain that it was likely going to have a rocky start. We would not get them perfect and it would be slow going. Our next estimation meeting would be better, and the one after that would likely be a little different as we learned what worked best and changed what we needed to.

The first requirement was discussed. When the five minute timer was up nobody was ready to give an estimate. I set it one more time and when it was up I called for estimates even if we didn’t feel ready, reminding people that we weren’t looking for perfect. A couple people tossed their cards before everyone else was ready. Half of the developers ignored any QA concerns. One of the QA people claimed ignorance of anything development related. I wouldn’t call it a total failure, but it was a mess. I talked about how our discussion was bringing out what each group of people might need to do and while we didn’t necessarily know their job completely, we could use that knowledge to frame relative effort required. The next one went a little better.

We came to the end of requirements and shifted to some bugs. These we did in hours, and everything went much better. There was still some contention with developers and QA not feeling comfortable figuring out total effort, but it was getting better. The big problem with this meeting was this shift. Using both hours and story point cards in the same meeting caused confusion. All of the other issues could easily be seen as relating to a lack of experience with this new form of estimation.

In a quick poll at the end everyone was OK with the new way of doing estimates. In talking with the project manager after the meeting she was happy with the results. We knew it would get better over time, but for the first time in a long time she felt the estimates were more accurate, and that the team all knew what was coming up. Over time this has proven to be the part that is most valuable to the team.

This was a great place for us to start our agile implementation within the limits we have. Our estimation process has evolved as we have looked at what works, what doesn’t, and what value we get from it. In a future post I will go return to estimates and explore how we do them now.