Agile Story Estimation: Points are not Associative
Their are two primary benefits to estimating effort in points instead of time. The first is for the development team. It is easier to estimate relative sizing vs trying to estimate the hours it will take. For example, a new requirement comes to the team in the form of a user story. They compare it to recent user stories that they have completed and determine that this new story is 3 points. It's bigger than the 2 point tickets that they have recently worked on but smaller than the 4 point tickets. This relative sizing is easier for human beings to estimate than absolute sizing.
The other benefit is for project management. They can see how many points the team completes in a week and can use that to inform their longer term roadmaps. Additionally, they can divide the total number of development hours across all team members in a week by the points they complete to determine how many hours a single point represents for this team. Another team may work on the same user stories, but for them a single point requires more hours. By doing relative estimation with points, it allows for more accurate and personalized predictions of how much a team can do in any given time period.
A few math concepts
Let's take a step back and relearn some basic math concepts called the commutative property and associative property. I will tie this into Agile story estimation, I promise.
The commutative property states that the order of operands does not effect the result. Addition is commutative while subtraction is not. Take a look at the below examples.
5 + 2 = 7
2 + 5 = 7
The order of operands for addition does not effect the result. However, let's look at subtraction:
5 - 2 = 3
2 - 5 = -3
As you can see, for subtraction, the order of the operands effects the result. While the commutative property is about the order of operands, the associative property is about the grouping of operands. Let's look at another example.
(4 + 3) + 2 = 9
4 + (3 + 2) = 9
As you can see, we can group the operands in any way, and the result is unaffected. Let's take another look at subtraction.
(4 - 3) - 2 = -1
4 - (3 - 2) = 3
For subtraction, the grouping of operands affects the outcome.
Applied to Agile development
Let's apply these concepts to Agile story estimation. Are Agile stories commutative and associative? Sometimes they are, sometimes they are not. It all depends on how you divide up the work. When "breaking down" some body of development work into stories, the goal should be to arrive at a set of commutative and associative stories. This would mean that the total effort that it takes to complete the stories does not depend on the order you do them in, how you group into sprints, and how you assign them to team members.
However, I have some bad news for you. This never works. At least not perfectly. Agile stories will always have some level of ordering to them. Additionally, grouping certain stories into the same sprint and assigning certain stories to the same person will always effect the total effort required to complete those stories. This being said, we should still strive for commutativity and associativity when breaking down development work. Stories that have a few minor dependencies on when you work on them and how you group them with other stories are easier to plan and roadmap than stories that have many major dependencies.
A concrete example
Let's look at some a concrete example of how this works. Let's say we have a new product to develop. We have broken up the work into the following tickets for a total of 39 points.
- (2 points) Bootstrap project
- (8 points) Create infrastructure
- (3 points) Setup CI/CD
- (8 points) Create search API
- (5 points) Create homepage
- (5 points) Create search page
- (8 points) Create login module
There are a few observations that we can make. First, the "Bootstrap project" ticket needs to come before almost anything else. Secondly, "Create infrastructure" needs to go before "Setup CI/CD".
For search, the "Create search API" needs to come before "Create search page". We could remove this dependency by using dummy data for "Create search page". If we do this then we will need a new story called "Define search API" that goes before both. We could do both stories at the same time, but may be less efficient. The order and grouping of tickets will affect the total effort.
There are also some less obvious things that you may only discover after digging into the details. Let us say that both the home page and search page use the same header and footer. In this case, whichever ticket goes first will create the header and footers, making the next ticket easier. Essentially, the 5 point homepage story plus the 5 point search page story is less than 10 total points, since some components of the two pages only need created once and then can be reused.
We could strive for associativity and commutativity by breaking down the tickets as followings:
- (2 points) Bootstrap project
- (8 points) Create infrastructure
- (3 points) Setup CI/CD
- (3 points) Define search API
- (5 points) Create search API
- (2 points) Create header and footer
- (4 points) Create homepage
- (4 points) Create search page
- (8 points) Create login module
While we can strive for these properties, we can never achieve them perfectly. Project managers, scrum masters, and developers all need to be involved in striving for these properties but flexible enough to work through situations where it is not possible to cleanly divide up and organize the work.
