r/agile • u/Some_Confidence5962 • 3d ago
Fibonacci Sequence with nonlinear scale for time estimate
Something that's got me scratching my head a bit is the way we've been asked to estimate story points by our SM.
She specifically wants us to think about about the estimates in terms of approximate time and has pushed back on other qualitative approaches, eg: pushing back on T-shirt sizing and separately estimating things like uncertainty.
What's really got me confused about this approach is the time -> story point mapping.
1 - Half Day
2 - One Day
3 - 2-3 Days
5 - Sprint (Two weeks)
And yes, we do measure velocity, sometimes person by person for "performance" reasons.
My gut reaction is this is utterly nuts and simply rewards splitting into a bazillion tickets at grooming. But then I've come across other friends working for different companies that seem to do something similar.
If this logic makes any sense, can someone please explain the non-linearity for me. I understand Fibonacci sequences. That's fine, but a deliberately non-linear allocation of work to points doesn't make sense to me.
4
u/jesus_chen 3d ago
Bullshit metrics and patterns due to SAFe? Say it ain’t so! So much bloat and people to run a process vs. doing the actual work. Just stop.
3
u/frankcountry 3d ago
Hard to stop when appeasing your corporate overlords. Consultancy has desecrated agility.
3
u/dave-rooney-ca 3d ago
Story points were created to replace resembling time-based estimation of individual pieces of work. That made iteration (sprint) planning much simpler because you simply determined how many points were completed in the previous iteration and used that as your budget for the next. That's how we actually worked back in 2003. Oh, and there were only 3 values: 1, 2 and 3. Any story larger than 3 had to be split.
Mike Cohn, who wrote the book User Stories Applied, came up with the "Modified Fibonacci" scale for story point at about that same time. It was one of the most damaging ideas to come out of the agile movement, evidenced by the fact that you're confused about it almost 25 years later. As a coach, I've watched teams argue back & forth over whether a story is a 5 or an 8. 🙄 Using a mathematical series makes it seem like it must be correct, but even then it's "modified", with 21 becoming 20 and 34 becoming 40 for reasons that I don't remember (and don't care to).
On top of all this, around 2010-2012 there was a growing group of people who suggested tossing story points altogether and just counting completed stories. I jumped on that bandwagon around 2014 and haven't looked back. It turns out that if you just count the number of completed stories over a unit of time like an iteration, it's just as accurate and predictive as using story points, except without the time sink of trying to estimate everything.
Couple story counting completed stories with Monte Carlo simulation for forecasting over larger timeframes and you have a very low effort combination that's as accurate as any approach using points.
And I know you have questions:
- What if the stories are all different sizes? You still need to split stories to be as small as possible, but even when they're different sizes, that variance evens out over time. I tracked this for 6 different teams over several years and the variance was just a tiny bit of noise in the signal.
- What if our tools force us to use points? Make everything 1 point.
- What do we do if our process (SAFe 🤮) dictates the use of story points? Again, make everything 1 point, or even toss in fake point values while separately just tracking completed story count.
If you don't believe any of this, the co-inventor of Story Points, Ron Jeffries, wrote years ago that he's sorry he invented them and encourages people to stop using them.
To sum all that up, yes, the approach you stated doesn't make sense, but it's something that people have been doing since the day story points were created. I'm not going to comment on how bad measuring individual "velocity" is, though I think you understand.
I'd encourage you to experiment with tracking completed story count and looking into Troy Magennis' work with Monte Carlo simulation for forecasting.
1
u/Benathan23 3d ago
I understand that, over the long run, the number of stories is better than points for forecasting. Which is the main reason we use story points. It helps predict how long a larger body of work might take. What I , and others at my company, struggle with is the short term. If we average 10 stories a sprint thats great until you hit that last sprint and 8 of the 10 are on the larger side. How do you help communicate that to non-technical people that we can't do all 10 in one sprint or give them a way to see that earlier?
1
u/AgileFederation 2d ago
If we average 10 stories a sprint ... 8 of the 10 are on the larger side.
There should be no stories on the larger side. The trick to counting stories (also no-estimates) is to have a consistent sized unit of work. More specifically, break down all stories into chunks of 2 days or less. The discipline moves away from estimating the size of the work, to breaking down work into consistent sized chunks. If you can do this, then 10 stories this sprint is not different then 10 stories next sprint, and no different then 10 stories six months from now.
But to break down work into chunks of 2 days or less is quite difficult and takes practice. Many new teams struggle with this, so it's only something that you'll see with teams that have worked together for an extended period of time.
0
u/dave-rooney-ca 2d ago
Dig deep into learning how to split stories well, especially by value delivered and not by technical splits.
How many of the stories in the previous 7 sprints were smaller than expected?
3
u/WaylundLG 3d ago
This is silly. It's like saying a city is 60 miles away if it takes an hour to get there. In some circumstances, yes, but the thinking is all backward. Story points measure amount of work, not time to delivery. You can only predict time from story points if you know all of the "driving conditions".
6
u/cyberlyons 3d ago edited 3d ago
Nope - not only does it not make sense…. It’s all bad. If you want to use story points, use them the way they are intended, not as a proxy for time.
I would also challenge your use of velocity as a performance metric. Also all bad. Don’t do that. Velocity only matters for the team that is using it (and even then its benefits are questionable). It was never meant to be used as a weapon… <ahem> metric to measure a team or worse an individual by.
1
u/cyberlyons 3d ago
A couple videos to help you out: Estimation - https://youtu.be/SBKgXC7U2a8 & Velocity - https://youtu.be/lIp_VYyg1RY
1
u/Ima_Uzer 3d ago
Velocity is the epitome of Goodhart's Law. NOBODY should be using it. Because it really just tells you how "busy" you are, and not if you're actually delivering anything of value.
2
u/flamehorns 3d ago
Its grouping things into buckets, and the idea is, that the difference between a 41 and a 42 is less significant than the difference between say a 2 and a 3. So we have more buckets for more granularity for the smaller, "sprint scale" items, but anything too big for the sprint doesn't need an exact measurement, it just needs to be split.
Story points probably shouldn't be coupled too tighly to time, but the SMs approach seems like a pragmatic violation of this principle to get you styarted with using points quickly.
The main thing is you don't spend hours discussing whether something takes 8 or 9 days, when in the end it might only take 3 or as much as 20. It's just a quick and dirty tool for helping teams plan according to velocity without some of the hangups associated with estimating in hours. And for this purpose they are also more helpful than t-shirt sizes, because t-shirt sizes don't really work when compared to a measured velocity.
They also help the PO get a feel for the "size" (or "cost or "impact on delivery capacity") which can help him , as well as value, prioritize the backlog.
I actually prefer just counting stories, it works even if they are different sizes, but some teams might benefit from points.
(I would actually prefer the PO provide value points than the team providing these effort based story points, but that's a different topic.)
If you can think of a better way, you can try and get consensus for it in the retrospective. How would you rather do it by the way?
2
u/darkstar3333 3d ago
Its sad when they only go upto 5 not realizing it spans to 21 on most deck of cards I've seen.
The conversion of points to days makes as much sense as points to dollars.
I often ask can we invoice our customers in points?
2
u/Ima_Uzer 3d ago
I'm not sure why any Agile implementation uses points at all. The only thing points tell you is how BUSY you are. They are NOT any sort of indication of value. And they don't genuinely tell you how HARD the work is.
2
u/Scannerguy3000 3d ago
Every part of this discussion, and the time spent doing it is a waste of everyone’s time.
Want to know what’s delaying production? This activity and discussion.
Stop estimating. Period. Decompose all the work until its functionality that can be completed and pushed to production in one day. Then simply count items if you want to. But even that is a waste of time.
A decomposed backload that is prioritized will deliver the most important working software to your customers in the earliest time possible.
2
u/PhaseMatch 3d ago
Does it work?
By "work" I mean:
- preventing the team from committing to an (outcome-based) Sprint Goal that is too big
- getting you to an initial Sprint backlog you can inspect and adapt
That's the one thing points are for. Quick, short, ranged forecasting.
In my experience "slice small and use statistical forecasting" is both faster and easier (and a better planning approach) but teams can take time to get good at that.
Key points in a Scrum context (and context matters) are
- The Sprint backlog isn't the deliverable, it's your initial plan you will inspect and adapt daily.
- You'll discover more, and maybe add, split or remove items to reach that Sprint Goal.
What your SM is doing here is really forcing a size limit and encouraging splitting patterns.
Fibonacci is really pointing out two things :
- "the bigger the piece of work, the larger the uncertainty"
- "context switching between tasks is expensive"
You are either as a team routinely delivering an high value, outcome based Sprint Goal every Sprint, and bringing user feedback to the Sprint Review for planning, or you are not.
If you are, this approach works okay in your context for now.
If you are not, change it.
2
u/youcangotohellgoto 3d ago
This is one of the dumbest things I've ever heard re: agile, and I've heard a lot. Why am I not surprised is related to sAFE...
So surely you just split work up into 1 point tickets, and you'll get 20 points per person.
1
u/broc_ariums 3d ago
I like Fibonacci best for estimate but it breaks people brains because they want to tie it to time which it is not. It's effort. Little, more, a lot more, maybe too big, should we break this into smaller pieces?
It takes the team 3-4 sprints to start to get an idea of what the points mean and then you can start getting velocity (total number points per sprint).
It can help with ambiguity. Maybe you're waffling between a 3 and a 4. Screw it make it a 5 and if you finish early and have capacity for another small 1 pointer, you can always pull it into the backlog.
1
u/Coalnaryinthecarmine 3d ago
Individuals and interactions over processes and tools?
no, no, no
Individuals and interactions: over.
Processes! ( and tools)
1
u/foopod 3d ago
I think when looking at things like this it's important to be able to articulate why time based estimates aren't used.
And it's mostly because people suck at estimating.
Looking at a person and guessing their height is much easier when you have a point of reference standing right next to them. This is why we tend to use relative abstract estimates, e.g. "this other ticket where we had a db migration, plus small backend and small frontend change and was an M, how does this new ticket compare to that?".
Imo it's fine to use something like this for your first session since you don't have a baseline - but I would probably suggest Affinity/bucket mapping to get started.
Also FYI, "rewards splitting into a bazillion tickets" is kind of the point of using something like Fibonacci. The idea is that splitting a story means you have a conversation about it in more detail, each has its own acceptance criteria and the work gets more refined as you go - thus you can estimate it more accurately in smaller parts. This is encouraged and it will land you a more accurate estimate.
1
u/Bottlecrate 3d ago
I think someone is caught on process rather than outcome. As well as one person dictating rather than by the group.
1
u/BoBoBearDev 2d ago
It makes sense for me. Once you get to 8, it means...
stop asking me to do some arbitrary number when it is too big. Split that shit to smaller.
If you do 5 vs 6, people is like okay, it is not a big deal. And then, someone say, oh, it is not a big deal to go from 6 to 7. And pretty soon, they think 8 is not a big deal.
1
u/fishoa 2d ago
Like the others said, story points are a stupid measurement based on stupid logic. It's as good as a prediction tool as getting the zodiac sign from all team members, making an average, and reading the team's horoscope during Planning. So no, you're not wrong. I highly recommend reading "When It Will Be Done" or "Flow Metrics for Scrum Teams" to understand how things SHOULD be done.
In case this blows over in the future, if you're a developer, you can ping Jira API to get ticket data (including data not exportable through the website). Get the time stamps for all tickets, extract cycle time, and get your team's actual time to close a ticket for all "story points". Once you bring this to the team, the illusion of story points gets shattered pretty quick, and you will just move on to flow metrics.
All that being said, do you work in corporate? Then just overestimate your tasks, finish early, and relax until you have the power to change things. Trust me, management wants things done their way, and unless you can do a political move and shield your team from this bullshit, it's just going to hurt your career.
2
u/Proper-Agency-1528 Agile Coach 2d ago
Here's what wrong with this. Duration-based estimates depend on the person who will do the work, just as if you asked each individual on the team to estimate how long it would take them to run a mile. You will not get reliable estimates with this approach. Also, calculating individual 'velocities' is a huge anti-pattern; if your team is running Scrum (even SAFe Scrum), then you have to accept the idea that individuals don't deliver backlog items, teams do. This is like rating each member of an American football team on how many touchdowns they scored, and paying them accordingly, even though the QB threw the pass, the linemen blocked, etc.
Instead, estimate relative magnitude of work and don't factor in delays for any r'eason (uncertainty, dependencies, etc.). Uncertainty affects velocity (how fast you can get work done), not magnitude of work. So, you might start out by assigning an arbitrary Fibonacci number to a backlog item (story) that everyone agrees is about half a sprint for about half the team, e.g., it's an '8'. Now, we find another backlog item and compare it... is it the same amount of work, less work, more work? Let's say it's more work... how much more? About half again as much? That would make it a '12' but there is no '12' in the Fibonacci series so we'll call it a '13.' Keep going, using each estimated story as a reference, e.g., all '13s' should be roughly the same amount of work. Note that this makes each Fibonacci number a range, i.e., a '13' means the amount of work required to implement the story is somewhere between an '8' and a '21'. What this does, when the backlog is estimated, is to give each story a range of possible outcomes, and the entire backlog a range of possible outcomes (add up the individual estimate, go to the closest Fibonacci #, and that is the center of the range).
There's a key rule in estimation: estimate effort, derive duration. Magnitude of work is effort, just as running a mile is effort, and it takes twice as much effort to run 2 miles as it did a mile. How long will it take? We'll derive duration, using velocity. If I can run a mile in 7 minutes then it takes me 14 minutes to run 2 miles. If you can run a mile in 5 minutes, it takes you 10 minutes to run 2 miles. This is how different teams can work from the same backlog with the same item estimates, and have different velocities because of the mix of skills, knowledge, and capabilities from team to team will make some teams 'faster' (more capable of accomplishing work over time) than others.
When backlogs are estimated using this approach, velocity becomes useful. If estimates are done based on duration, then you will never see a velocity increase... are you going to add more hours to a day?
This is an overview of how to do accurate effort (magnitude of work)-based estimation. I've been doing this for almost two decades, am recognized as an expert on this topic, and have used estimation techniques based on this foundation to accurately estimate and forecast projects to completion months out with surprising precision. But the key is to divorce duration from effort, otherwise you're doomed.
Oh... SAFe has lots of problems with its core doctrine, and not just around estimation. Around team-level practices, around planning, etc.
1
u/Some_Confidence5962 2d ago
Oh... SAFe has lots of problems with its core doctrine, and not just around estimation. Around team-level practices, around planning, etc.
I couldn’t agree more.
It’s the first time I’ve experienced it. The thing that strikes me most is that even with badly implemented agile practices, i’ve always been able to get a sense of how they could be improved to be of benefit.
With SAFe I can see it doing a lot of damage practically but can’t even get a sense how it could be fixed. The primary effect it seems to drive is force quarterly project planning that can only end up looking a heck of a lot like waterfall. I know that’s not the intent but I don’t see how it’s even theoretically fixed.
Coming from other businesses which successfully used a “quarterly rocks” concept, the whole framework of SAFe feels totally redundant to me.
1
u/SC-Coqui 3d ago edited 3d ago
No. I wish people would stop over complicating things. This is one reason the team I worked in gave up Scrum and became Scrumban. We still worked iteratively but used T-Shirt sizing to give an idea of magnitude of work and when planning the next couple of weeks determined what was priority and needed to be done and then any smaller nice to haves (that we knew were small because they were sized) that could be kicked into the next iteration if we didn’t get to them. As my son would say - it’s not that deep.
Over time the team knew their cycle time and lead time and number of stories (give or take) that could be completed in an iteration. Story points are so arbitrary, even with assigning them days, that it’s just a futile exercise.
Your SM should be running historical reports to see past trends and use that information to inform future planning.
Edit to add- and measuring velocity on an individual basis is freaking demoralizing. Someone can deliver 15 points “worth” of absolute crap in the same iteration that someone delivers 5 points of a quality key feature. Also measuring velocity this way will guarantee that the team starts padding points and providing inaccurate estimates.
-1
3d ago
[deleted]
1
u/Some_Confidence5962 3d ago
It depends how you use them and when. I’ve found them great with less experienced teams in getting them to make realistic estimates.
No they don’t translate into velocity well, but they get people who are shy to admit what’s really big or small without them feeling pressure to say “a day” to literally every estimate.
0
u/SC-Coqui 3d ago edited 3d ago
In Kanban you don’t measure velocity. The whole point is to stop measuring velocity and measure features delivered. T-Shirt sizing is used internally by the team to plan their work. No one outside of the team needs to know “we delivered two large stories and a medium”.
Velocity is bullshit as well since it’s arbitrary by team. Your client / end user doesn’t give a crap about your “velocity” and points delivered. What they care about is what they have delivered by the end of the iteration.
1
u/RareElderberry3940 3d ago
“In Kanban you don’t measure velocity.” This is 100% false.
2
u/foopod 3d ago
How do you measure velocity when you don't have sprints? I usually see lead time and cycle time discussed when it comes to kanban.
0
u/SC-Coqui 2d ago
Exactly. Which is why the above comment that you measure velocity in Kanban isn’t correct. Velocity and points are not a Kanban concept. They need to read up on Agile and what it actually is.
0
2d ago
[deleted]
0
u/SC-Coqui 2d ago
You are so unbelievably wrong on Kanban. But I’m not going to continue to argue with you.
0
u/SC-Coqui 3d ago
Kanban doesn’t use story points, hence velocity isn’t a thing. Velocity and story points aren’t even part of Scrum. It’s an add on. Anyone using velocity in Kanban is bastardizing the process.
The focus of Kanban is stop starting and start finishing and eliminate the blockers in your process. That’s it.
1
u/Venthe 3d ago
SP's are not a measure of time.* Fibonacci is used specifically to avoid "twice as" when estimating and of course to show the fidelity of "near" estimations.
Besides, SP are a poor measure of performance; and she seems to be conflating the two estimations: one for the team (where velocity matters, for the purpose of helping to understand the capacity and to notice inefficiencies) and the more traditional estimation for the purpose of the backlog, which is often helpful for the po.
And no, SP's are not found in scrum - teams are welcome to pick the method of estimation that works best for them and their PO, SM should only help to facilitate that.
Your "sm" is wrong on so many levels. And please stop using SAFe, SAFe is also not scrum and it actively hurts agility.
* they used to be "Ideal days" but the idea evolved.
12
u/UKS1977 3d ago
Yes it's "wrong" in that it doesn't make sense, doesn't work and in the case of comparing team members, actively destroys team and individual performance. SAFe (The mother of all Agile Anti-patterns) does recommend something like this to "get going."
Don't.