Software planning is a thorn in the side of certainty-loving businesses. Leaders need to make plans and predictions that can make or break the future of the company atop the stubbornly unknowable nature of building things that have never been built before. To make this possible, an elaborate fiction of software planning has been created to make it appear that creative work can be planned and coordinated like an assembly line. It rests on the core idea that developers can correctly estimate the amount of effort it will take to build novel capabilities, and maintain the things they have already built. And it further assumes that they can do this in the face of a large number of unknowns about their own or others’ capabilities, institutional obstacles, and changes in the technology landscape.
Modern agile planning, which is built on top of this fiction, starts with the right question: what work is the most valuable? From there, each piece of high priority work is estimated using one of a few techniques, “Planning poker” using Fibonacci numbers may be the most common. After the team agrees, the numbers are summed and compared with some previous benchmark like velocity. If the numbers are reasonably close, everyone is happy and the work is “committed” for the current sprint. If there is a wide discrepancy, then there are a few different outcomes:
- If the team is mature and practicing agile effectively, they will determine what work is the highest priority and move stories into later sprints until the numbers match.
- If the team is immature, or under substantial pressure to perform all of the work on the board, they will likely agree to take on more than they feel comfortable doing.
Then the Sprint is run and either the team estimated well and gets all of their committed work done and everyone gets a pat on the back, or there are unforeseen issues. In the latter case, there are again a few different outcomes:
- If the team is mature and practicing agile effectively, they will look to adjust the total points to better reflect the work if it remains the highest priority, or swap in work of roughly equivalent size will blockers are resolved, thus keeping the overall velocity constant.
- If the team is immature or lacks the support of the business, they will be encouraged to power through and make sure their committed work is complete. They did commit to it after all.
So, if a team is mature and able to withstand outside pressure, and is very good at estimating consistently, then this manner of planning will leave both sides satisfied. But in every other case developers will be perceived as “failing” in some ways. That is an extremely high standard, but a necessity to preserve the fiction that a fixed certainty exists upon which strategic decisions can be made.
Sharing the Risk
Typically, the engineering organization is entire buffer between the expected outcomes and the messy reality of building new software, which means that a failure of any kind gets attributed to engineering. As discussed in the previous post, this punishment for uncertainty will push the team towards patterned and therefore predictable solutions, which is beneficial for the short run, but almost certainly detrimental in the long run. These solutions quickly become laden with technical debt as patterns and processes continually improve.
At the same time, the need for the business to have predictability in delivery is very real. The key is that the risk must be shared between both sides with an agreement on the acceptable level of risk, and how resources must be allocated to achieve the desired timeline with that level of risk. The 100 points system is designed to facilitate that process.
100 Points Overview
The team starts by dividing a pool of 100 points into 4 buckets, where each point represents 1% of the team’s total effort.
- Allocated to new feature work
- Allocated to work that makes current and future feature work faster
- Allocated to required maintenance or backlogged technical debt
- Allocated to work that eliminates future maintenance or technical debt
The specific division set up for a particular sprint depends on a number of factors including the stage of life of the project, the size of the existing technical debt or required maintenance, and deadlines that exist outside of the project (such as an advertised feature launch or a critical security vulnerability). Greenfield projects will likely place more points on new feature work and work to make future work easier. Project with substantial backlogged technical debt may need to allocate more towards maintenance leaving little to the other categories, but that surfaces an important problem for those types of projects rather than leaving it as something to be solved by the engineering team. Many forward-thinking organizations want to maintain a fixed percentage of work allocated towards 2 and 4 and this system easily facilitates that.
Once the allocation has been determined, the remaining items are taken from the backlog in priority order, as would normally be done. However, rather than give a point estimate of effort, the question becomes “What percentage of team effort will give sufficient confidence that this work will get to the desired state (as defined by this team’s product owner and definition of done)?” A high priority item with a rapid expected delivery will likely need a lot of the team’s effort to complete, and allocating a large number of points to it is the only way to meet that goal. If there are instead a larger number of “nice to have” features, those same points can be distributed across them with some likely to complete and others not as much.
The end result is a set of planned work where the points reflect priority as reflected in percentage of team effort. This is the essence of the “commitment” being made under the 100 points system: the team will allocate its effort in the agreed upon way.
Simple Example
Team Centurion has 6 developers, 2 QA engineers, and a Product Owner. 11 stories are pulled in to the current sprint as the set of prioritized work, 8 new stories and 3 carry over. To begin, they determine how to allocate their point buckets. The organization wants them retain 30% of their effort towards work that makes future work faster (2), and work that eliminates future maintenance or technical debt (4). The decide that some refactoring is long overdue on a core component, so they decide to allocate 20 points towards that work, and the remaining 10 is kept for tech debt or maintenance items to be determined later.
With the remaining 70 points, they now look across the remaining stories working with the product owner to allocate their resources. Stories 1, 2, and 3 are the carryover stories and are highest priority. The team determines that each could be completed with about 5 points worth of effort at a 90% confidence level. Stories 4 and 5 are must do as they block other teams. To team agrees that with 15 points apiece those stories are 90% likely to reach completion. Stories 6, 7, 8, and 9 are the next highest priority but if they don’t complete this sprint they can carry over without penalty. They are each given 8 points which the team gives an 80% confidence level to complete for 6 and 7, a 60% for 8, and a 10% for 9 . Stories 10 and 11 are the lowest priority and are each given the remaining 4 points.
Once the initial allocation and confidence levels are set up, it can be adjusted in many ways to satisfy different concerns. If the business would like a higher than 90% confidence level in the two highest priority stories, they might push 10 and 11 to the next Sprint and reallocate those points. Or even decide that they really only care about 1-6 right now and shuffle all the points to those items to make sure they are completed.
This process forces both sides to think about effort levels and tradeoffs rather than play games with velocity or estimates to try to make things work out. At the end, the priorities are clearly stated and it is clear how team resources will be spent.
Next Up: Challenges to the 100 Points System
100 Story Points 