Story estimation with cross functional team
Hello everyone, sorry for the slightly redundant question, but I haven’t been able to find a clear answer yet.
I am likely moving from a developer role to be a Product Owner, and I have a bit of confusion over estimating story points on a cross functional team. We currently have 5 engineers, two of which are AWS/infrastructure folks, and three are software developers. Of the software developers, one focuses on frontend GUI work, one focuses on database and backend API work, and the other does more business logic work.
How do others estimate points for stories when only one or at most two people are actually familiar with the required work involved in order to know how complex, time involved, etc it is?
We currently do something vaguely like planning poker, but generally 3-4 people have very little idea and end up throwing out guesses if they even vote at all. Many times we simply ask the one person likely to work on the story what their individual point estimation is.
My best guess is that long term the solution to this is to get the team to be more T-shaped so that others are more familiar with work other than their own, but our product is rather large, so I’m not sure how realistic that is with so few engineers.
I have a bit of confusion over estimating story points on a cross functional team. We currently have 5 engineers, two of which are AWS/infrastructure folks, and three are software developers
Which is it? Do you have a team, or 2 AWS/infrastructure folks plus three software developers?
I'd suggest that if you had a team, they'd recognize that while they have their own specialisms -- which is fine -- they have a shared accountability for producing a Done increment of work every Sprint, and for estimating how much work they can take on accordingly.
This is something they will get better at over time, as they gain a shared experience of reality and a consensus view of reality. They will become more T-shaped, as you put it.
So never mind how good or bad they are at joint estimation right now. Do they have a shared sense of accountability which would make them even want to achieve a consensus?
- If they do, perhaps you don't really have a problem to solve.
- If they don't, at least you know what the real problem is.
@Ian is spot on with this response. The only thing I would like to add to from his response is the "want to achieve a consensus".
Story points are guesses made at a point in time based upon the information available. They are not tied to any type of actual effort. They are relative effort to other work that has been done in the past. Not everyone has to be able to do the work but they should be able to understand the complexity of the work. The team element in the exercise is to share any information you have that could be relevant, even if you will not be doing the work, so that all of the people involved in the estimation can come to a consensus on an estimate. This is not "tell me how long it will take you do the work". It is "let's all agree that this work is more complex than that other piece of work and could take more effort based upon what we know at this very moment."
As teams do this collaboration over time, they will become better at reaching consensus across the various disciplines that they represent. That will make them more of a single team and less of 2 AWS/Infrastructure folks plus 3 software developers.
This is why you have never found a definitive answer. You probably have been looking to find a way to explain how a UI developer could estimate infrastructure work in an AWS cloud. I hope this explanation helps.
Thank you both for the replies, they definitely help clear this up for me.
I will say to address both comments that we do have a single cohesive team despite how I may have made it sound with developers + infrastructure folks. Despite our specializations, we are all focused and working toward the same goal for the same product.
This is not "tell me how long it will take you do the work". It is "let's all agree that this work is more complex than that other piece of work and could take more effort based upon what we know at this very moment."
This is helpful as well. I think it would be helpful for everyone on the team if I were to comb through old stories and pick out some good examples for reference stories to help reinforce that point, because our "estimation" currently does often come down to one or two people saying how long they think it will take them. It's common for POs at our company to use story points that directly correlate to # of hours we think it will take to complete, which is a mindset I hope to change over time.
You might want to read this blog post from Ron Jeffries, the person who is said to have invented Story Points. It might give you some more insight.
https://ronjeffries.com/articles/019-01ff/story-points/Index.html
'our "estimation" currently does often come down to one or two people saying how long they think it will take them.'
My initial thoughts regarding the above comment:
If you're relying on a single person to provide you with an estimate because they are most likely to work on it, what do you do if the business is ready for the team to work on it, but that individual is unavailable? Do you keep the original estimate even though the work is going to someone who didn't provide that estimate? Do you re-estimate? Do you hold the work up because the ideal person to work on it is unavailable?
You might want to read this blog post from Ron Jeffries
This was a really good post, thanks!
what do you do if the business is ready for the team to work on it, but that individual is unavailable?
The way that would work for us historically is that the story would just wait. And if someone else did pick up the work, we don’t change the estimates.
I’m soaking up a bunch of ideas of ways that we can improve some of this, but I don’t want to come in and flip everything upside down. I want to experiment with maybe one or two tweaks and see how the team likes it.