Take the complexity out of planning by using it as the metric

Creating a product is inherently riddled with unknowns and hurdles. As we refine and define processes to streamline the confluence of a team’s efforts, following those processes can be distracting. Process should help streamline work, not create it; it is the ever present balancing act of development and managing a team.

For this post I wanted to share one aspect of that process that tries to measure your team’s output called “Story Points” where the “story” represents the work requested and its set of requirements, and the metric applied to it called a “point”. Since estimating time is almost always inaccurate, processes like Scrum work within that reality by using points instead of time; it embraces the grey of estimation.

Problem is if you try to be too exacting with those points then you have gone full circle, back to the original problem of an inability to be accurate. In our team we developed a loose definition of what each point means so that product owners and developers can communicate with a “rule of thumb” quickly in planning meetings, that way the “hard work” can be focused back on output.

We use fibonacci to list our point values. Why? Well, it’s not a scientific answer but we believe it does a better job enforcing the concept of “fuzzy numbers” into more separated buckets. In our point breakdown, we relate points to complexity, not time, and summarize the amount of unknowns into the point as well. Here is our list of points and their meaning:

1 = Simple text change 
2 = Simple code change
3 = More complex code change

Notes: 1 – 3 are changes that the developer has a strong grasp and awareness on what needs to be changed/created and where it needs to be done. The more complex the number of changes are (i.e. you work between many function vs working within one function) the higher the number, but in all cases it’s a fairly well known problem/solution. Then we have:

5 = Complex code change with a few unknowns
8 = Complex changes with many unknowns

5 and 8 represent complex changes that involve known unknowns. For example, a developer may know what is being requested but that developer may have no idea how to do it. We find that when a 5 point story appears in a project (and definitely when 8 pointers show up) then it’s a red flag that something may not be clear in the requirements, or the story has become too bulky and needs to be broken down into smaller chunks. In rare occasions, something ends up simply being a 5 or 8.

In the world of product development completing smaller chunks of work help you deliver and iterate on your results more quickly. Any time there is an opportunity to catch a bulky implementation its a good thing. With this point system those warnings are built into the pipeline naturally.

Hope that helps add consistency and ease to your development process!