This post is mirrored from it's original location on the Ackama Blog
The points don't matter; if it sounds like a line from Whose Line Is It Anyway? that's because it is.
When it comes to our Agile process, there's one thing that is quite often misunderstood by everyone in the room: sizing.
Over the years, I've worked with a number of teams who have conflated points with time. It's easy to understand why this is tempting, especially for a product owner or project manager. They want to manage their risk by understanding how quickly the team is getting through the features they want. However, if you find yourself having a conversation with your product owner where one of you is trying to understand how long something will take based on the team's point estimates then this should be a giant red flag for you.
In the aggregate, a product owner may be able to work out a rough projection of feature availability by aggregating total stories and how long they take, but it requires a lot of data and this is only really feasable for long running projects. Most scrum masters of long-term projects I have spoken to freely admit that graphs of velocity (points over time) – even ones carefully controlled for the ebb and flow of team members – often bear no discernable relationship to either the hours worked or productivity of the team.
Velocity, after all, is a noun meaning speed and direction. I would argue that when your team starts measuring velocity, the direction is almost always “down”.
What are they really for?
If the points don't matter then what are they really for? We've already discussed how points don't equal time and they don't equal productivity. Even developers with many years experience in various flavours of the Agile process believe that points are there to measure effort. Somehow effort is supposed to be magically defined as “the amount of work we need to do that specifically isn't measured in time or money”.
When you stop and examine this definition, you'll quickly come to realise that it is completely meaningless. If it's not time and it's not money then how else are we supposed to measure our work? Lines of code? Number of unit tests?
What if story points aren't for measuring at all? What if story points are really there as a conversation starter? If people on your team give wildly different estimates of the effort involved then that's a conversation you need to have. Let's throw out some scenarios:
- Problem: Senior dev says it's easy but junior dev doesn't fully understand the problem. Solution: Conversation.
- Problem: Dev team says feature seems like a “5” but tester thinks that it's an “8”. Solution: Conversation.
- Problem: Product owner thinks it's a “2” but scrum master thinks it's a “5”. Solution: Conversation.
I think you can see where I'm going with this.
Who should be participating in sizing exercises?
If you're following the reasoning above then you come to realise that every single person in the room should participate in sizing. Developers, designers, product owners, testers, project managers, scrum masters. Everyone.
The most common complaint I get when talking to people about why they don't participate in sizing exercises is because they don't feel that they have the expertise or experience to “be allowed to size”. My contention is that no matter what your role is, you do. Your lack of technical knowledge or experience may lead you to ask interesting questions of the technical staff or unearth varying expectations of the complexity of the feature.
Invariably the next question I'm asked is “doesn't this mean that sprint planning meetings take ages?” My answer is maybe. Certainly it will take longer if there are a lot of surprises in your sprint planning sessions; however, there are some strategies you can use to mitigate this: good backlog grooming being the most important. Expect a blog post about that in the near future.
Hopefully, I've convinced you that no matter what your role you have value to add and conversations to have. Go forth and make up points!