CURSE Your Way To Better Scrum Story Pointing
One of the main challenges teams face when adopting Scrum or other agile methodology is when they’re confronted with the concept of a story point for the first time. User stories are short tales describing some functionality the user wants from the user’s point of view (hence the very uncreative name). A very common way of estimating the time, complexity, effort, etc. of a story is to use story points. But that’s often where teams short-change themselves – and where a simple adjustment can make a world of difference.
When a lot of teams start using story points they typically begin equating one story point to one day (half a day of development and half a day of testing). This is a good guideline to start with, but it’s very incomplete and misleading. A lot of people begin thinking that if one point equals one day that eight points equals eight days and twenty points equals twenty days (leading them to believe they can have two people complete it in a two-week sprint – which generally doesn’t happen). Rather, we should be considering effort as only one aspect of a story point.
Given this oversimplified and misleading view, we need to start considering all of the aspects of a story point. If we think of a story point as a diamond then CURSE represents the different facets of the diamond through which we evaluate the story. This is likely to give a more complete picture of the actual work the team will need to complete for the story to be delivered. And you’re probably asking yourself now – “great, but what the heck is CURSE?” As well you should.
CURSE is an acronym I learned from a co-worker. I’ve not found it readily used anywhere else, but I find such great utility in it that I feel it worthy of a post. And the acronym is the following:
- C is for Complexity. This is how complicated, intricate, involved, integrated, etc. the work for a story will involve.
- U is for Uncertainty. This facet constitutes the certainty (or lack thereof) for the work that needs to be done. The team may be unfamiliar with the technology or uncertain how a particular element of the story may impact architecture or design.
- R is for Risk. This encompasses how dangerous a requested change or enhancement may be to the overall system, design, or architecture.
- S is for Scope. Scope is how much work or how far-reaching particular changes are.
- E is for Effort. This is what we typically associate with story points. It represents the actual work that’s going to be done, the implementation of the user story.
When looking at all five facets, it’s easy to understand why story points can be quite large for some things that may seem very simple and straightforward. A couple of examples I’ve used recently might help explain some of the disparity.
- In the first example, I described a user story to remove a particular column from a database (which is actually a bad example of a story, but sufficient for illustrative purposes). The Product Owner was asking the team to remove the column but was shocked at the points associated with it. “Why so high?” they asked. “Well, dropping a column is easy,” replied the developer. “But it may break everything in production. It’s not complex, the scope is limited, and we’re very certain how to do it. And while the effort is low, the risk is really high.”
- Our Product Owner asks the team to move 5,000 rows of data from one table to another (again, not a good story), but with one major caveat – all 5,000 rows need to be moved by hand. Again, a large estimate because while complexity, uncertainty, and scope are low, the risk of introducing issues and effort for moving the data are high.
Understanding that points don’t equate to days (via any conversion mechanism) is often a challenge for traditional project management-minded folks. When we use CURSE to describe our story points, we get a broader vision of the work that needs to be and it’s often a more realistic one as well. And when everyone in the Scrum team (including ScrumMaster and Product Owner) are aware and buy in to the methodology behind it, we’re able to better communicate the challenges our teams face.