The team lead wants to test planning poker as well. Thoughts?
For every other team I have seen it is a waste of time, you either under estimate how many points something is and you get moaned at you are late or you over estimate and you are praised for delivering early.
I pretty much caveat every single estimate I give (either time or the made up points) and say "if you want accurate estimates, a good rule of thumb is that I spend 1/4 of the time estimating to planned work - so if I think it will take 4 weeks, I should spend 1 week estimating" - no one ever wants you to do the accurate estimate so when I am moaned at because the estimates are incorrect I refer back to this statement.
What is the actual goal? Is it to track a teams progress (track by actual delivered work), is it to know how long something will take (story points are a distraction), is it to see how much work a team can do in a sprint (remove the 1 day planning/retro and you get an extra day to deliver the work), is it to fit into a bigger team of dependencies (story points, again, are a distraction).
If you are using story points to avoid figuring out how long something will take, then be brave and figure out how long it will take.
(sorry turned a bit ranty!)
In the true spirit of Lean, eliminate waste - the wasteful time of estimating things and the overhead of that. When using kanban flow instead of sprints it really doesn't matter what any estimate is.
This smells like someone above is asking when they can have something done so people in the middle have to come up with something.
Maybe the team lead/mgr can test doing the estimating themselves and letting the team just do the work. If you've committed to a feature or fixing a bug and it takes longer or shorter does it matter?
No, but we’re using story points to consume time while still estimating work on hours. Why? Irrational mix of cargo cult practices imposed by management with no articulable rationale.
> Been going back and forth internally to understand the true value of story points in estimating sprints.
Used properly, story points mitigate various problems with estimating intellectual work; basically, teams are empirically better and chunky relative estimates than detailed time-based estimates, but also tend to waste a lot of effort for no return when doing the latter. So, ideally, with SPs you do chunky relative estimates quickly, and over time use statistical analysis tonget a picture of both the expected time and variance (both of which will slowly change over time) that those chunky relative estimates translate into for work items and overall sprint size.
A sibling comment recommends no-estimate flow based development methods, which are often ideal if the dev team has no outside interactions for which estimates matter (or these are rare and unpredictable, so that ad hoc estimation of particular items on demand is more appropriate); if you have such interactions regularly, though, you need the minimum cost way to get estimates accurate to within the limits of available information, and story points, used properly, can be part of a process that provides about the best solution to that available.
As the first part of my comment indicates, story points can be (and often are, IME) used improperly in ways which arr pure waste, too, though.
Unfortunately I’m still trying to find a way to replace it and get buy in from colleagues and management.
1. It doesn’t really help planning work, unless it’s always the same work. It’s a placebo.
1.1. e.g. team velocity is 20 points , but things are going to work very differently in a sprint with 4 stories of 5 SP and 10 stories of 2 SP. Mainly because the SP includes risk and complexity.
2. Recently saw someone comparing two teams, one doing 80 points the other doing 30. The problem: the former SP range was up to 13, the latter SP range was up to 5, rarely 8. So it still not transferable and meaningless outside it's own context.
3. Not comparable between peers, it doesn't map to the same levels of complexity, amount of work and risk for different people. Mostly people map SP to a range of days or hours and it differs as it's not standardized among peers.
In my team setting I would prefer no estimates and a commitment based approach, but that kinda leaves management without numbers to count besides features and bugs delivered (which is good enough to me).
Everything else is just a way to approach this as effectively as possible.
So the more experienced a team the less they use whistles and the more actual time estimations.
1. PO would create user stories.
2. Devs volunteer to do tech analysis
3. Team get together and do planning poker.
4. If there are more unknowns, ticket will get deferred/spit
We have decent estimates, shared understanding and everyone in team can do work.
- when we write the specifications for a project, we also create the stories and estimate their points
- when planning the sprint, we quickly estimate them
The points are useful to us because we roughly know how many points we can handle in a sprint, thus we know what we can commit to do in the sprint. We thought of using "short/medium/high" instead of points, but it's harder to get a feeling of whether we can embed one more story in our sprint.
We're not strict on scrum or stuff like that, but estimating properly is still useful when we have a roadmap to stick to. This is how we can know for sure which projects will be removed from the roadmap as the time goes.
One thing I want to try is to assign 2 points fixed to all tickets by default and let each individual dev manage their own meaning to the points. So for A it could be 2 points = half day work, for B 2 points = 2 days, and maybe C doesn’t want to use points so it’s all 2 points.
This way you still get a more granular view into the progress, but it’s not annoying for the devs nor it becomes a way to compare “A did more points than B”.
And as others pointed out, the value is in the conversation it drives and being able to skim a list of tasks to get a rough feel for the scope of the project you're working on.
"Ask HN: Is your team using story points to estimate work? Why or why not?"
6 points, 13 comments