Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Business Analysis, Information Technology
The Fibonacci Scale
Hello All,

The other day I was introduced to planning poker which used the Fibonacci sequence to estimate the story points to various user stories in our Agile company project.

I just wanted to know what your view point is on this method and whether or not you use it in your environment as well.

Let me know your thoughts.
Sort By:
Page: 1 2 3 next>
Victor -

Using a modified Fibonacci sequence (modified, because once you get up to 13, the usual subsequent numbers are 20, 40 & 100) is a fairly common approach used by teams who are relatively new to relative sizing (pun totally intended!).

The benefit for such teams is that being a non-linear sequence, they are less likely to get into analysis-paralysis which can happen when sequential numbers are used. To paraphrase a great analogy provided by Mike Cohn, imagine the numbers to represent buckets of different size and the team has to figure out which bucket a given quantity of water might fit in.

However, once teams mature, they should get better at slicing their work items small enough. Once this happens, the Fibonacci sequence can be put away in favor of just counting how many small items can be completed in a given amount of elapsed time and using that throughput value to forecast.

Kiron
...
1 reply by Victor Ginoba
Dec 09, 2019 2:01 PM
Victor Ginoba
...
Thanks Kiron. Your comment makes sense. Especially, when you mentioned that once the teams mature, the sequence will become irrelevant as you should get a better sense of how long a small unit of work will take to be completed.
I'll piggyback on what Kiron stated. On a project team I was a member of earlier this year we started with the sequence as he mentioned. We had some "larger" stories that sized out at 21, 34, 40 points. These stories happened to fall later in our development cycle so we came back to them. When we revisited them we ended up breaking these down into several smaller stories of 3-5 points. Ultimately, we ended up with a state very similar to the one Kiron described. This was easier for the team to deliver continuously and embrace the concepts of lean and agile.
...
2 replies by John Farlik and Victor Ginoba
Dec 09, 2019 2:04 PM
Victor Ginoba
...
Hi John,

Thanks for your comment. Can you elaborate on why some of your user stories reach 21, 34 and 40 points?
Dec 09, 2019 2:31 PM
John Farlik
...
Sure. I believe that when we did our inception and original story generation we weren't aware of some of the details that were needed, but the team knew it would be alot of work. So compared to our 2-3 point stories, the 34 & 40 stories were quite large. However, through learning and execution of our sprints we learned what the detailed work needed to be for some of the larger concepts. We revisited them in about sprint 4 or 5 during our weekly backlog grooming and broke them apart. The project had about 18 sprints in it total. It was a concept very close to "progressive elaboration" along with release planning that helped us to make these decisions.
There is no other method that can deal with the high uncertainty Storie Points has intrinsically. My recommendation is using it always. And if you need to assign a number over 13 then review the user storie. Is not needed and has no justification to use number above it.
...
1 reply by Victor Ginoba
Dec 09, 2019 2:05 PM
Victor Ginoba
...
Thank you Sergio. Always appreciate your comments.
Dec 09, 2019 12:37 PM
Replying to Kiron Bondale
...
Victor -

Using a modified Fibonacci sequence (modified, because once you get up to 13, the usual subsequent numbers are 20, 40 & 100) is a fairly common approach used by teams who are relatively new to relative sizing (pun totally intended!).

The benefit for such teams is that being a non-linear sequence, they are less likely to get into analysis-paralysis which can happen when sequential numbers are used. To paraphrase a great analogy provided by Mike Cohn, imagine the numbers to represent buckets of different size and the team has to figure out which bucket a given quantity of water might fit in.

However, once teams mature, they should get better at slicing their work items small enough. Once this happens, the Fibonacci sequence can be put away in favor of just counting how many small items can be completed in a given amount of elapsed time and using that throughput value to forecast.

Kiron
Thanks Kiron. Your comment makes sense. Especially, when you mentioned that once the teams mature, the sequence will become irrelevant as you should get a better sense of how long a small unit of work will take to be completed.
Dec 09, 2019 12:53 PM
Replying to John Farlik
...
I'll piggyback on what Kiron stated. On a project team I was a member of earlier this year we started with the sequence as he mentioned. We had some "larger" stories that sized out at 21, 34, 40 points. These stories happened to fall later in our development cycle so we came back to them. When we revisited them we ended up breaking these down into several smaller stories of 3-5 points. Ultimately, we ended up with a state very similar to the one Kiron described. This was easier for the team to deliver continuously and embrace the concepts of lean and agile.
Hi John,

Thanks for your comment. Can you elaborate on why some of your user stories reach 21, 34 and 40 points?
Dec 09, 2019 1:42 PM
Replying to Sergio Luis Conte
...
There is no other method that can deal with the high uncertainty Storie Points has intrinsically. My recommendation is using it always. And if you need to assign a number over 13 then review the user storie. Is not needed and has no justification to use number above it.
Thank you Sergio. Always appreciate your comments.
...
2 replies by Sergio Luis Conte
Dec 09, 2019 2:21 PM
Sergio Luis Conte
...
You are welcome. There is a very interesting work on the matter I fully recommed to read that belongs to Mike Cohn.
Dec 09, 2019 2:28 PM
Sergio Luis Conte
...
And just to remember something obvious but is critical to take into account when estimate with Storie Points. remember what a User Storie is. By definition, "just a placeholder, an invitation to take about it". You do not have a requirement on hand or a least a well formed requirement which mean something that will allow to create the solution or part of it.
Dec 09, 2019 2:05 PM
Replying to Victor Ginoba
...
Thank you Sergio. Always appreciate your comments.
You are welcome. There is a very interesting work on the matter I fully recommed to read that belongs to Mike Cohn.
Dec 09, 2019 2:05 PM
Replying to Victor Ginoba
...
Thank you Sergio. Always appreciate your comments.
And just to remember something obvious but is critical to take into account when estimate with Storie Points. remember what a User Storie is. By definition, "just a placeholder, an invitation to take about it". You do not have a requirement on hand or a least a well formed requirement which mean something that will allow to create the solution or part of it.
Dec 09, 2019 12:53 PM
Replying to John Farlik
...
I'll piggyback on what Kiron stated. On a project team I was a member of earlier this year we started with the sequence as he mentioned. We had some "larger" stories that sized out at 21, 34, 40 points. These stories happened to fall later in our development cycle so we came back to them. When we revisited them we ended up breaking these down into several smaller stories of 3-5 points. Ultimately, we ended up with a state very similar to the one Kiron described. This was easier for the team to deliver continuously and embrace the concepts of lean and agile.
Sure. I believe that when we did our inception and original story generation we weren't aware of some of the details that were needed, but the team knew it would be alot of work. So compared to our 2-3 point stories, the 34 & 40 stories were quite large. However, through learning and execution of our sprints we learned what the detailed work needed to be for some of the larger concepts. We revisited them in about sprint 4 or 5 during our weekly backlog grooming and broke them apart. The project had about 18 sprints in it total. It was a concept very close to "progressive elaboration" along with release planning that helped us to make these decisions.
...
1 reply by Victor Ginoba
Dec 09, 2019 2:34 PM
Victor Ginoba
...
Thanks John, for the clarification.
Dec 09, 2019 2:31 PM
Replying to John Farlik
...
Sure. I believe that when we did our inception and original story generation we weren't aware of some of the details that were needed, but the team knew it would be alot of work. So compared to our 2-3 point stories, the 34 & 40 stories were quite large. However, through learning and execution of our sprints we learned what the detailed work needed to be for some of the larger concepts. We revisited them in about sprint 4 or 5 during our weekly backlog grooming and broke them apart. The project had about 18 sprints in it total. It was a concept very close to "progressive elaboration" along with release planning that helped us to make these decisions.
Thanks John, for the clarification.
Page: 1 2 3 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

I'm lactose intolerent. I have no patience for lactose and I won't stand for it.

- Jerry Seinfeld

ADVERTISEMENT

Sponsors