My dev likes to tag features as Small, Medium, Large, X Large and XXL when we discuss features. I am curious how other PMs size their stories. Please share any thoughts or best practices.
5 Likes
My team usually avoids picking anything over 8 and suggests to break a 13 point story into 2 or more parts.
Also, we all suck at estimating. That’s the universal rule i have noticed in 4 companies i have worked for.
5 Likes
We don’t even go to 8 on our team - capped at 5, anything over gets broken down. We found it makes it more manageable.
5 Likes
@Felipe, That’s quite logical and can be thought of.
@Ahmad, That is wise of you.
5 Likes
Thanks @Maria, can’t take credit for it because honestly, it’s just pragmatism.
Our sprint velocity makes it very clear that taking anything beyond a 5 is a recipe for carryover. Additionally, there’s also a psychological factor that kicks in when you see a range of small and large numbers mixed in that makes the larger activity more scary than it needs to be.
Reducing that range makes the 5 only slightly more complex than a 3 and the 3 is slightly more complex than a 1 so it becomes a little easier to digest. But if you had 1,3,5 and 8 then somehow their minds short-circuit and they fret about the daunting work in the 8 pointer task.
So I’m happy to kinda chop it up into smaller, bite stories for them to handle per sprint if it means they can give consistent amount of attention through a larger initiative (using the airplane spoon, making airplane sounds and saying “here’s the plane coming in for a landing!” optional)
5 Likes
Thank you @Ahmad, for the additional color on this. I’m very pleased to see that some teams learn from the mistakes of planning fallacy!
4 Likes
We use t-shirt sizing when grooming (the sizes you list) and Fibonacci for pointing (1, 2, 3, 5, 8, 13).
3 Likes
@Natasha, What is the benefit of using both? I guess I am trying to understand the use for both. I thought T-shirt sizing would do the same thing as Fibonacci pointing - define the complexity of US/task/feature
PS - My Sprint backlog is not going to be used by dev but my PM team to manage pipeline of things we can develop over the next several months
3 Likes
We sometimes use t-shirt sizing when we need a very high-level estimate, usually for quarterly planning and then use the Fibonacci sequence when we need a more refined estimate at the sprint level.
3 Likes
@MariaWilson, Basically exactly what has already been said. I use the t shirt size for prioritization so that I know what the value x effort is for the features we want to tackle. An XL might sit in the backlog or be closed because it’s just not worth the effort, or I might take it back to the drawing board to see if there are less burdensome approaches to tackling the problem. By the time we get to planning, barring any surprises we’re taking on these tickets and the pointing is to track velocity and make sure everyone agrees with the initial estimate.
2 Likes
@Natasha,
Two questions:
I fail to understand how you would use a size of M or XL to prioritize when the size really is conveying the complexity and effort involved in developing it?
Second question: In our company the dev does the T-shirt sizing with us and so the high level discussion on what needs to happen takes place during T-shirt sizing phase. So I am wondering why is there a separate need for pointing when the complexity and understanding of work involved is already reached in the T-shirt sizing process?
2 Likes
@Maria, IMO you need to know complexity to prioritize. If I’m building a toaster and the ideal feature toasts bread in 1s but would take our engineers years to build, or we could toast bread in 1m and have that done next week, I would prioritize the latter.
For your second question, if the whole team comes to an understanding in grooming on the complexity and specific effort involved, then maybe you don’t need story points. In my experience, grooming is done with only the senior developers and we aren’t hashing out 100% of the details, just enough for an estimate. It’s typically pretty accurate, but sometimes when you get to planning and pointing, a developer who will be working on a feature identifies something new that changes the estimate.
2 Likes
As long as you’re applying it consistently, and only using it as a relative comparison against each story, it really doesn’t make a difference what you use.
It’s useful for the measure you’re using to be a number though, as it allows for easier comparison of groups of tickets or periods of time, but it’s all dependent on the team you have and what do you intend to do with the estimations.
There are no objective “best way” to do it though, introduce small change, monitor, review and decide as a team.
1 Like
@MarcoSilva, That makes sense. Thanks
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.