While salt adds flavor to an entree, too much salt makes it inedible. Similarly, only using ‘salty’ story point estimates for a release’s schedule projection, may make the release untenable.
“How long will it take you?” is an often asked question of managers to developers. Industries that use highly repetitive steps or processes can measure the time taken to perform a task across various employees and create estimation standards for the effort per step or process. Unfortunately, in software development, the procedure to hammer out the desired customer outcomes, the design, the code changes, validation and deployment can vary greatly from one customer outcome to another, and from one developer or team to another.
In traditional development, we attempt to reach agreement on all functionality to be implemented in a large batch of work, often embodied in a release. We do sufficient design to understand the complexity and scope of the changes before starting implementation. At about 30 to 40% estimated effort spent on the project, we believe that we’ve done enough work to be able to estimate the size of the remaining work and project a ‘commitment’ date for completion. These estimates, from my recent experiences, are often off by 25% to more than 250%. When the reality finally surfaces, the release is subject to requirement changes and functionality reductions.
Enter in agile development. Here we reduce the batch size down into small increments that each must meet a known, high-quality definition of done. We track the rate of accumulated small increments as we build up sufficient value to release.
A way of reducing the batch size is to break up a large requirement into small user outcomes called user stories, and to estimate the work for each user story using story points. Story point estimation uses a Fibonacci sequence of sizes that each team after a discussion agrees to assign to the user story. If size is too large, the team with the product owner often breaks apart the story into multiple, smaller outcomes where each has a smaller batch size with a smaller story point estimate.
As the team progresses since story points are team specific, they record their accumulated story point velocity for each sprint. To estimate a completion of a ‘release’ or an accumulation of stories, the team charts out remaining unfinished stories with story points, their velocity and their confidence factor. This projection is a burndown rate over time thus keeping the team specific story points within the team. For those who have taken Scrum Master training, this approach should be fairly standard.
In a few organizations, the engineering managers ask me why they couldn’t just use time or effort estimates per story. To get a schedule estimate, the managers divide the team’s summation of effort estimates by the available team engineering size. The managers believe that everyone understands effort estimation given that the size of each story is small and are all broken down into small increments, the effort estimation should be reliable. If there’s slippage, the engineering manager can put pressure on the team or the individual to make good on their effort estimation commitment.
This way of thinking is intoxicating to engineering managers and leaders: just demand that each story point be an engineering day of effort. Export all of the stories with their story points from the team planning tool, like Jira, into a spreadsheet. Add up the story points. Add up available team members’. Divide to get days remaining. Project out over a calendar (don’t forget holidays and vacation!). Now, we have a schedule commitment.
I liken this intoxicating simplicity to a chef who only cooks with the most common seasoning, salt. While every recipe will likely include salt, all recipes don’t include only salt as a seasoning. Imagine if a chef only seasoned every dish with salt. This is akin to an engineering manager boiling down story points to engineering days. What’s missing from this dish are the other seasonings in the spice rack. For example, relating seasonings to things teams should consider when story pointing: cumin to complexity, garlic to familiarity and/or uncertainty, peppercorn to validation changes, cardamom to clarity of outcome, turmeric to architecture impacts, chili pepper to user impacts, basil to migration realities, thyme to risks and cinnamon to team dynamics.
Each seasoning adds something to the entree. Consideration of overall complexity of the outcome relative to how the product is currently structured adds how much change may be needed. Familiarity and uncertainty of previous team experiences with similar outcomes can add or remove story points because of shared understanding. Having to completely restructure how the product is validated or no-change to validation adds or takes away story points. Outcome clarity and/or how the outcome does or does not fit within the current product architecture may increase the team’s coordination with those who decide architectural decisions. If users have to learn, unlearn and/or relearn something about the product, that deserves consideration in the story pointing due to user interface design and validation. If the internal mechanisms or data representations have to change and therefore a partial or complete migration has to be planned, will definitely add work to be done. If there’s an external risk, such as another team is working in shared code and the teams need to coordinate their changes, the estimation should be adjusted accordingly. Lastly, internal to the team, there may be a need for critical resources, skills and/or knowledge that are committed elsewhere (like to a family’s vacation), those should be reflected in the story point estimation.
Since the team has likely dealt with these considerations story after story, sprint after sprint and release after release, they are best situated to enter into the deep, experience-based collaboration needed for efficient story point estimation without being forced into the overly simplified short-hand of engineering days. A team acting as a chef looking at a user story as an entree will want to consider all of their seasonings, including salt, for their recipe. The mixture of all required seasonings may need to be used to make the entree deliciously flavored for consumption.
The key ingredient necessary for being able to estimate time is a clear and mature ‘definition of done’. Regardless of the entrees needing just salt or a large mixture of seasonings, the rate that the team is able to complete small increments of ‘done’ work establishes the consistent rate of work and allows the team to project a credible schedule.
So, if you’re an engineering leader who is demanding that every dish on the menu must only be prepared with salt as a seasoning, you’re going to end up with simply too salty story points and inedible releases.
