I was recently asked by a user if I had a way of analyzing a team’s maturity with the way they were pointing.
This made me think: what sorts of things does a new Scrum team do (or not do) when compared to a veteran team? This won’t be a tidy algorithm to judge your team, but hopefully, it’ll help guide your team towards where you want them to be.
What is a story point?
Anything you’ve ever read about scrum will tell you: a story point measures complexity, not time.
It’s a hard concept to get; it took me 5 years to finally understand the nuances.
Harping on the difference between time/complexity doesn’t seem to make sense intuitively. For example, if something is complex, it’ll take me more time. And if it’s simple, it should be pretty quick. Why all the fuss?
Let’s back all the way up to why we use Scrum, or XP, or anything like this in the first place. In the olden days, we used to waste time in meetings, creating Gantt charts, giving estimates and making projections — they were always wrong! So we wasted a lot of time doing things that couldn’t be trusted.
We were told story points were invented because “time estimates are inaccurate.” This is true, but a lot of people think this implies that story points are more accurate than time estimates. That’s not really the case. Time estimates are inaccurate, but so are story points.
Story points are better because they are more flexible. They make the estimating and projecting process more efficient. Your team can spend less time planning and more time doing work that produces value, which is what we all want. And with proper story points, your planning and projections will become more accurate. It’s a win all around.
What does “complexity” mean?
This is a tough one to grasp and is easier to explain with an example.
On day 1, you have a backlog of stories, with no estimates on them. So the team reads through the backlog and chooses one that’s about a “medium” in size — and assign it a medium in points, perhaps an 8. This is your “keystone” story.
Then you go through each story in the backlog and compare it to the keystone. Is it more complex or less complex? If less complex, that story is a 5. Way less complex, it’s a 3.
You know a story is more or less complex by several factors. Does it have some unknowns? Unknowns make it more complex. Is it difficult to test? That’s more complex. Does it rely on 3rd party APIs? That’s more complex.
Every time your developer says, “well I’d need to do some research,” that just means it’s more complex. Choose a bigger number and move on.
Don’t equate points with time
People love to equate story points to time — this is wrong. Why? As a team matures, their velocity should increase. But if 5 points = 1 day (or whatever you choose)… what happens to a 5-point story that’s 6 months old? It used to be a day’s worth of work, but now it’s only 3/4 of a day. Maybe now it should be 3 points? If you’re not constantly updating your points, then you’re unable to project your completion date.
If your points don’t equate to time, and your team gets faster, you just increase your sprint velocity. Our velocity used to be 90 points per sprint but now that we have a new build server, we can do 94 points per sprint. There no need to re-estimate the entire backlog to make accurate projections about the future.
If points relate to time, then why use points at all? Points were originally conceived because developers are TERRIBLE at estimating time. It’s not their fault though, it’s complex work and it’s just really hard to do.
Here are some indicators that your team is pointing with time, instead of complexity:
A developer says, “I can’t point something because I need to do more research.”
Not always, but many times, this is a sign of using time. They want to suss out all the details, so they can guess the time it will take.
A developer says, “it’s a 3 if I work on it, but a 5 if Jerry does it”
This is another measurement of time. What they’re saying is that it’s less time if I do it. But with story points, we don’t care who does it. We know the average velocity of the team is 90 points per sprint. Jerry might spend more time on this task that I would, but that means I’m working on something else. So just follow the average and don’t worry about the specifics of who might do the work.
Don’t debate small point differences
We don’t argue between small point differences. If it’s a 1, 2, or 3, it doesn’t really matter. If a lot of people say 1, a few say 2, and one person says 3… we still choose a 3. It’s not worth the time to discuss differences of 1 point. Choose the big one and move forward.
Don’t obsess over perfect estimates
We don’t worry about being perfect, we shoot to be 80% right. When teams are new to scrum, a lot of emphasis is put on having perfect estimates, because, before scrum, we always needed perfect estimates. Sometimes an organization even demands the scrum team have perfect estimates. This is not good and something a Scrum Master would need to work hard to address. Once the development team is in a safe place, they can quickly assign points and get to work. Because getting work done is the real name of the game. The points are there only to help you look into the future and project when some milestone will be reached. 80% accuracy is the sweet spot. Better than that and you’re wasting too much time in planning. Worse than that and the rest of the company can’t accurately plan.
Don’t succumb to pressure to change a number of points
It can be hard when you have a demanding PO saying, “is this really a 5, shouldn’t it be a 3?” Or some executive says, “why does Team A complete 100 points, but Team B only does 75?”
A less-mature team would break under the pressure. They would try to get the 5 done in the time of the 3 and ultimately it won’t work. It might be obvious immediately because they don’t complete the entire sprint. Or it might show up down the road because technical debt was added. Everyone will see it in a few months when new features take longer than expected or are full of bugs.
Or when the executive makes them feel bad for not doing the same number of points; a less-mature team would just pad their numbers. They wouldn’t actually increase speed.
Mature teams know they are in charge of quality. No one else is. If someone wants them to get something done for less, they have conversations about it. They explain the tradeoffs and the technical debt that would result.
And if an executive implies that their productivity is lower, they would dig into it. Perhaps the executive was comparing apples to oranges and came to the wrong conclusion? Or maybe the mature team’s productivity actually is lower? I would expect the mature team to dig in, figure out what’s wrong (if anything), and make appropriate changes to improve. They wouldn’t just pad their numbers to satisfy the powers at be; that helps no one.
What about you? Have you experienced anything that differentiates a mature team? Please share; we’ll update this article with new tips as they come in and give you credit.