Most Agile teams are comprised of dedicated developers, testers, and often technical writers. When it comes to estimating story points for a team's effort on an issue it requires that all of the members provide input. With these different concerns, does it make sense to have different categories, such as development and testing, to share the same story point assessment? What if we could estimate and track multiple categories separately for different team functions while leveraging the same Sprint window?
In a previous article, I discussed a concept of how to jump-start a team to use story point estimation; the article can be found here. This article is a follow-up discussion on Agile story point estimation that examines an idea that I had for improvement in the processes we were using. I often worked to ensure that our Agile practices were being followed. I wanted input from our developers as much as our testers. This was not only important for Agile buy-in but to ensure the accuracy of the story points the team generated. Developers often look at their issues through their own perspective and testers are no different. It’s these perspectives that help ensure we deliver a quality product over time. At some point, I began to wonder if it made sense to include everything in a single story point for an issue. I suspect it is possible for us to break this down into discrete categories so that we can improve our estimating ability. Additionally, I expect that there are advantages to tracking the different categories' velocities and efforts independently.
It’s the unique perspectives that the team members bring that helps ensure good story point estimation.
A core requirement in any estimating is that all of the team members are present when discussing the backlog issues. When it comes time for estimating story points the issues are reviewed and estimated for each of the categories: development, testing, and documentation. These are typical categories from my experience but you may have additional areas of interest that you may want to consider. By having each category estimated individually by the team, this will allow for a more accurate representation of the work effort and complexity required for implementation. Additionally, the process provides better insight and transparency through the additional data that will be generated. Each category will share the same pool of available story points for a Sprint but maintain their own respective velocity and burn down or up charts.
A mock example in Figure 1 below demonstrates a partial Sprint backlog for a team using the traditional story point estimating process. The issues reviewed by the team are X, Y, and Z. For each of the issues, the team has gone through and estimated the effort and complexity and come up with 13, 13, and 8 story points, respectively. This means the team has a total of 34 story points allocated for their Sprint. In Figure 2 below, the same issues are estimated using story points by category. This means for each of the issues the team has gone through and estimated their respective category efforts for development, testing, and documentation. Each category will contain their own respective story point estimation and for the same Sprint, their allocation so far is 10 total story points; four less than the traditional method. This information will help feed into the individual categories for burn down or up charts, and velocities and will lead to better transparency of an issue's total effort, and what the team can accomplish.
Figure 1 Mock X, Y, and Z Issue Efforts
Figure 2 Mock X, Y, and Z Issue Efforts by Category
The velocity is the number of story points completed within each Sprint by the team. The velocity value helps the team determine how much workload they are able to handle. The velocity can vary for many different factors such as reorganization, customer availability, vague requirements, and resource conflicts, but typically will converge over time for a team. For this process, each category will have their own respective velocity.
We can also maintain an overall summary velocity that will help show the big picture by improving management insight. This is a summary of the different categories and will represent the total story points completed within each Sprint. The mock example shown in Figure 3 below has a total of 34 story points spread across the Sprint's development, test, and documentation categories. As shown, the mock categories for development, testing, and documentation were assigned 21, 8, and 5 story points respectively.
Estimating by category leads to better transparency of an issue's total effort and complexity.
Figure 3 Mock Category Velocity
Burn Down Chart
As each category has its own velocity, so too will they have their own respective sprint burndown charts. Below in Figure 4 are the mock category burn down charts representing a month-long Sprint for each of the different categories previously discussed.
Figure 4 Category Burn Down Chart for a Sprint
Another implementation might involve having only those group members for the categories who are implementing the issues perform their story point estimation. In the previous example, our development, testing, and documentation efforts and complexity will be estimated by the developers, testers, and technical writers respectively. This means developers will only estimate their implementations while testers will estimate their respective efforts and complexity and so forth. Each team shares the same Sprint as before. However, the caveat with this approach is unless you have more than one person for each category the estimates will probably be poor. In my experience, you typically need a minimum of three people to develop a good faith effort estimate for an issue. This doesn't preclude the process from being applied but I expect it will limit its usefulness.
You need a minimum of three people to develop a good faith estimate.
Story point estimating is a useful tool for figuring out how much effort an issue will require to implement. It manages to abstract away the inaccuracy of man-hour estimation that developers have traditionally used for development. However, depending on its implementation, important details can be hidden from both the team and managers alike by utilizing a single story point for a whole issue. This concept, as discussed, is intended to help expose those details by providing a separate story point estimate, velocity, and burn down or up charts for the different categories of effort. The end goal is more transparency for the team through better estimates by using categorical story point estimation for effort.