In a previous post we looked at story points in a Scrum Agile setting, why they matter for predictability and why the numbers in estimations can (and should) get as big as they do.
Scrum is one of the most common methods of working with developers in Agile today. The popularity of this method is both useful – because it gives us a rich ecosystem and common language with peers – and an issue – because popularity leads to misunderstanding and misuse.
Story points in particular are a trap which many Product Managers have trouble managing with developers and with their stakeholders.
Complexity isn’t time
You go to a sprint planning call, you look at your velocity over the last few sprints. You’ve averaged 50 points in your last 6 sprints. You look at your backlog, you pick up 50 points of work, you start the sprint and you’re done.
This is wrong.
It’s one of the most common things I see in Product Management and delivery.
This method of over reliance on points leads to:
- A lack of proper examination of work items up front
- Inaccurate Sprint commitment leading to incomplete sprints
- Inaccurate timelines in your projects
- Annoyed Stakeholders
Points are not time, are not there to plan what work you’re getting through in a sprint and shouldn’t be used as short hand in that way as a result.
Your points tell you how complicated and unknown something is. This is not a measurement of time, it’s a measure of how wrong your plans might go. A 1 point ticket is something which is simple to develop and deliver, we know everything about it, the likelihood of it going wrong is low. This doesn’t mean it’s always going to be quick.
It’s vital to keep this separation if you’re building a backlog using story points. If you’ve got a completely hard coded website and you need a developer to change every button from blue to green by hand, it’s going to take a while (humour me so I can make the point, I know there’s plenty of ways to do this more efficiently).
Similarly, if you have a task which your team has estimated at 5 points, it doesn’t mean much in terms of time. The change might need a lot of checking, might require a lot of time and effort to understand and to correct the wider system for. Maybe you won’t need very long for a given 5 point task, that’s great, the next 5 point item won’t be the same.
Looking at each story at the start of a Sprint, working out how long the item might take and only accepting the amount of work which you can complete in the time allowed is needed. Your development team shouldn’t have to worry about the number of points they’re picking up in a given sprint, and shouldn’t. The team should focus on completing as much as possible in the 2 week period without worrying about anything else.
Velocity Charts Suck
Jira and tools like it are a common way of managing a Scrum team. They come with plenty of handy extras to automate reports, drill down into metrics and generally give some nice looking graphs for people to look at. Unfortunately they also encourage behaviour which doesn’t help your team.
Velocity charts in particular are badly misused. They show the commitment and achievement in points over the last few sprints and line each sprint up in order so you can look at whether your team is committing to more or less than they are delivering in a sprint. That’s it, that’s all the chart is mean to do – give you a general sense of whether the team is getting better or worse with their ability to predict what they’ll get through.
Unfortunately, development is also one of the most expensive things a business can do with its budget. There’s constant pressure on getting more out of a team, and many Stakeholders love a graph.
Show someone a graph with a bar that’s lower than the others, they’ll ask why.
Show someone a graph with decreasing points achievements over time, they’re probably going to ask why your team is less productive and what you’re doing about it.
Velocity charts encourage the push for immediate consistency, if not an increase in points over time. This is both unrealistic and not what velocity, or points, is for.
A given one point task might take a day or 3 days, depending on what it is. This is because the points tell you about complexity and unknown-ness, not time. That means that it shouldn’t be a surprise if one sprint picks up 30 points of stories and the next picks up 50. The pick up is about the amount of time your developers have in their week and how long they think the work will take.
With this in mind, all your velocity chart should be used for is to check that your team is delivering what they’ve said they will that what they (and you) are telling your stakeholders will be done in the next sprint is going to be, and that they’re picking up as much as they can.
Talking about points in a particular sprint isn’t very useful as a result. Instead it’s your role as a Product Manager to make sure that your stakeholders are aligned about what they’ll get for the time spent, and to defend your team when the next sprint contains 20% fewer points than the previous.
Points aren’t resource
Because of the pressure for productivity, many team leaders in Scrum – PMs, lead developers, even some Scrum Masters, will start building spreadsheets for everything. Spreadsheets for velocity, spreadsheets for notes, spreadsheets for bug tracking and spreadsheets for resource management in sprints.
Before you know it, you have a spreadsheet presented at the start of every sprint planning call – how many people are on the team, how many points has the team achieved over the last 5 sprints, how many people are available in the next sprint. Suddenly, by the power of excel formulas, you have a number of points allocated to each developer, and because someone is on holiday next sprint they are expected to complete half as many points as normal.
If it sounds convenient, it’s not. If it sounds efficient, it’s not.
What you’ve just bore witness to is the implementation of a toxic way of working which encourages rushing, poor solutions and metrics gaining from your developers, and the treatment of people as production lines from whoever’s bright idea this spreadsheet was. Best intentions aren’t a redeeming quality here.
Development is not a sausage machine – your team is not chugging through their target output of nicely packaged items, passively waiting for input and giving a predetermined output. Development is a creative, knowledge based activity, as much an art as a science, and is rarely bound by simple predictability.
Any spreadsheet mapping points to people to sprints is wrong in essence. It assumes that all work is homogenous. It isn’t. Treating it as such leads to unrealistic output expectations, missed targets, stress and friction. I encourage you to do away with them because of this.
Summing up
Flies are interested in chocolate ice cream and dog muck in relatively equal measure. They might look similar as a distance but one is distinctly less scrumptious than the other.
Similarly, story points are a nice way of considering complexity of a project or backlog and giving us a simulacrum to help with business planning. Trying to use them as a short cut to time, resource or level of output it likely to leave a bad taste in everyone’s mouth.
If you’re going to use Scrum and story points, you have to implement a 2 tier process. Points exist to talk about complexity, what might go wrong and whether any given investment is worth it based on previous experience with similar complexity. It is a metric which should face out from the development team to help steer decision making. It is not a number to check delivery, a stick to urge on your dev team or a shortcut for the lazy to plan or report by.
PolyArch Product Management 