Musings on the arbitrary number we attach to tasks & stories

Once per moon, we find ourselves discussing both what dimensions we should consider when we’re doing our Backlog Refinement and what types of work should receive Story Points to begin with. Occasionally, the term →“Business Value” is tossed into the conversation, but for my heavily backend-focussed team, it is very difficult to attach that particular metric to a highly technical task – and we currently have a lot of them.

This article originally aimed to conclude that conversation, a publicised Working Agreement if you will. It may serve as inspiration to others who wish to look at their pointing strategy through the lens of a Backend team. But as with most things on the internet, YMMV.

Issue Types

We work with Product Backlog Items (PBI) that can be categorised as one of the following:

Story

Captures work from an end user’s perspective, with varying definitions of what an end user is (for us, it can be another system consuming our public API). They typically follow the format of “As <who> <when> <where>, I want <what> because <why>”.

Stories are pointed.

Task

Describes an often technical aspect of an overarching goal. This could be a necessary refactoring, foundational work, paying back technical debt, or general housekeeping chores.

We point Tasks.

Bug

Represents a defect, something that isn’t working as intended. Bugs have varying priorities: some have a very low impact with known workarounds, the more urgent ones affect production and need to be addressed right away.

Some Bugs we point, some Bugs we don’t:

• High-priority bugs that need to be added to current Sprint probably represent rework – a missed edge-case or something that slipped through QA. As such, it should not count towards the team’s →Velocity as that work should have gone into previous Sprints… so to speak
• Bugs for which we have workarounds or whose impact is considered low should be part of the normal prioritisation process. Attaching a number to it will help weighing against other items in the Backlog.

Spike

Work to explore a new technology, test new processes, eliminate unknowns (see below, →Entropy). The goal is not to ship production-ready code, but rather to provide a proof of concept. Code produced while working on a Spike might deliberately forgo tests or sad path handling.

The main output of a Spike is information. The information is shared with the team. We currently do not point Spikes, but we time-box them (~2 days).

Epic

A container for related issues of various types. Ideally, they have a defined end-date and all its member issues (Stories & Tasks, mainly) are defined & scoped together to avoid too much context switching.

Possible anti-pattern: using an Epic to group related tickets in such a way that the Epic grows and grows.

Interpreting Points: The Three Es (3Es)

I understand story points to be one of the following:

1. Entanglement (as in: how many connections / interactions / dependencies)
2. Effort (as in: how time consuming is the actual work)
3. Entropy (as in: state of disorder, The Unknown)

Entanglement

Entanglement reflects how many moving parts have to be considered, the literal complexity of the feature. Higher complexity will translate to more diligence considering side-effects or edge-cases, as well as requiring a more thorough QA process.

Effort

Effort can be a measurement for how laborious a task is, even if it’s not rocket science. An example would be restructuring a code base where the goal is clear, but it will involve renaming many files and module names.

Entropy

Entropy expresses the uncertainty around a given task. It can cover blind-spots about the implications of a change, lack of experience with the domain or technology, a placeholder for the unknown Unknowns that might be uncovered while working on the task.

Note: if there’s too much entropy, creating a →Spike first is advisable.

Business Value

Now, the Three Es don’t include the hallowed Business Value. After all, everything in agile software development is about continuously delivering value, right?

Unfortunately, there is no objective scale by which we can measure Business Value. For some cases, “revenue added / cost saved” would be a good unit of measure, but “customer satisfaction” is nigh impossible to translate to money, whereas “better fault tolerance” requires a lot of effort (and guesswork) to put a € sign next to it.

Business Value is also time-dependent: it exists within the context of the organisation’s current situation and direction. Whatever arbitrary value we assign as Business Value for a story today might receive a completely different rating next month when re-evaluated.

Business Value is not a metric to feed into a team’s Velocity. It’s a means to prioritise work!

Further reading: Business Value by Erik de Bos.

Velocity & Capacity

In Agile software development processes, the Sprint Velocity is a metric for the output of a team, measured in Story Points completed. Cynically, one could argue that it’s also a metric on how good the team is at estimating, but let’s assume that outliers in estimation are inevitable and are evened out over time.

A (somewhat) deterministic pointing system where units of work (represented in PBIs) can be compared is key to assess the output of a team. Hopefully, the 3Es above help with that.

Now, Velocity as a metric for a team’s output (i.e. the sum of completed story points) is meaningless if it’s not correlated to the input of the Sprint: the person-days that were available. It’s the Story Points / Available Capacity that really matters. The rationale being: one Sprint might have lower output because ⅓ of the team was recharging their batteries on well-deserved PTO (reduced input).

If you want to track the relative efficiency of your Sprint, the relation of completed Story Points to Days Available provides the best insight and it also leads to more precise capacity planning: by calculating, say, a 4-Sprint-average of that ratio, you’ll end up with a multiplier to give you a good idea about how many Story Points you might complete in the next Sprint.

The 4-Sprint-average is (0.5 + 0.63 + 0.67 + 0.82) / 4 = 0.655. If you have 36 person-days available in your upcoming Sprint, you should aim for ~24 Story Points.

It’s controversial if you want to count unfinished business towards your delivered output. I get why you wouldn’t want that – a User Story that isn’t fully done doesn’t provide value – but we also established that we won’t look at value.

Being able to accurately plan what can be delivered in a Sprint is much more tangible than the incorporeal value and to that end, we split issues based on what was completed and what will roll over to the next Sprint.

Conclusion

In general, we already have a good grasp on how how many points to attach to a PBI – being primarily an #Elixir team, we have mentally assigned @default_points to 2 and just use the module brain attribute in Scrum Poker. This is a good sign, as we're apparently doing ok at splitting work into bite-sized chunks already. But for more complex issues and when the estimates given differ a lot, it's good to do a sanity check by looking at the three dimensions Entanglement, Effort, and Entropy separately.

Additionally, finally having resolved that considering Business Value as something that should go into a PBI's story point estimation was a huge win.

Header photo credit: PxHere, CC0 Public Domain