When switching from Waterfall or another process to Agile, one of the most difficult aspects can be adjusting to the use of story points for estimating issues. Most experienced developers have estimated using hours for issues by internally evaluating what the effort and complexity of the problem is based on prior experience. However, experiences can differ significantly from one developer to another. For many developers, the abstract concept also eludes them. We devised a process to help with the transition from traditional estimating using hours to story points when migrating from an active project.
As a team lead, I had previously seen the difficulty in making the transition from man hours estimating to story point estimating after switching to Scrum. Our product has been in development for many years with successful deliveries to our customers. The product deliveries included a minimum of our software, user manuals, administration guides, and test procedures. We also were fortunate to have a large repository of completed issues and the hours associated with them. In a normal Agile process, the estimating grows more accurate over time for the team. What I desired was a solution that minimized the time for developers to build a consensus for estimating using the story point methodology.
To begin with, we needed to leverage the prior completed work and the hours for our product. We created a list which provided a sampling from minor issues that covered spelling or typo corrections, refactoring, through major issues such as feature enhancements. We also scheduled a block of time for the initial estimating. We pulled the issues to be reviewed and screen shared the content. As a team, for each of the issues, we collectively went through the effort of estimating each one. This allowed us to view and discuss the content together. Everyone was given an opportunity to review the issue. After the review, we each picked a story point card and revealed them all at the same time. Generally, if there was a grouping, we tended to end up with the majority story point. However, there were times when we debated some of the issues because our selections differed significantly. As the process went on, we often found ourselves comparing the issues to prior ones we just estimated. We discussed if the issues were less effort, the same amount of effort, or more effort. This helped us to refine and improve our estimates. Other times, we were able to come to an agreement on the amount effort needed to work on the prior issues. We eventually developed a consensus for the effort for the lower story points. As an example, a 0 story point for the team was a simple documentation update that might take up to two hours. A menu change to the UI might have a value of 3 story points, as it takes around 4 to 8 hours to complete. As expected, the larger the effort, the larger the story points and hours the effort required. As your team goes through its own process, they will also develop their own sense of what the effort for the different story points represents.
When estimating story points, it’s important to compare the issue with prior completed work. Is the issue less, about the same, or more than XYZ? As you go though the process, be sure to keep this in mind.
Figure 1: Historical artifacts converted to story points
We realized, however, that there were two caveats with the process. In certain cases, some of the developers had more knowledge of the prior work performed. As it turned out, this was not a major issue, as, generally, it was localized to a single developer who resolved the issue. The other caveat was what we needed to consider when estimating the effort involved. The complexity of the issue was factored into our effort. We also needed to factor in the testing and documentation. A minor issue that changes the UI of our product might be a simple code effort but the effects often have ripples that result in modifications to testing, both for procedures and automated testing, and documentation that included screen shots and user manuals, as seen in Figure 2 below.
The process of estimating story points is not a job for a lone wolf. Each member of the team should be involved the process as it is essential for the Agile buy-in of the team.
Figure 2: Ripple effect of a minor issue
Learning to apply story points can be a challenging problem, but hopefully, the experiences outlined here will help. Most teams are fortunate to have a sizable list of completed issues and the hours worked to complete them. Your team can also leverage your artifacts to practice how to perform story point estimation and get a jump start on developing a consensus for your team. Managers, on the other hand, can leverage the effort to help estimate actuals using the consensus and linking to the known hours for issues that have been previously worked on and resolved. Your team will develop their own consensus for the categories of work to be performed. The end result is an early start to having an estimation process that will continue to improve over time, while becoming more accurate.