I like to think about such things, thanks for sharing Maarten. Thinking about what’ll happen in a team with tasks in many different sizes. I saw teams having a good benefit of the flexibility in story points because they were able to use their average velocity (for them! 😊) during the planning to avoid dramatic overcommits.
When such a team has stories within the rage from 2-5 and will replace them with a 1 from your approach, they’ll lose sharpness.
How did you observe the switch on the estimation method in your teams?
can you comment on your definition of cycle time? Is it from the first time it was discussed in refinement to production deployment? Or from when it was brought into the sprint from start to Done (and maybe not actually deployed to Prod)? Etc. I've definitely moved into the camp that uses anything but Story Points...but that's a really hard change for teams to make. So I really appreciate any sort of experiment to see if we can do better. One more question - is this really just a different way of estimating and planning using throughput? Basically, how many work items can we complete in a sprint on average.
The moment we started working on it, after refinement, so it excludes the part where you refine it as in progress work.
However, around 80 percent was refined during Sprint Planning, so it would not affect the median much, but it would definitely add outliers to the average.
After a quick reading/scan of Nick's post, Escaping Story Points with Right-sizing, I assume that the time-box of 5 working-days is connected to the average cycle times below 4 working days and the median cycle time of 3 days or less. Am I correct?
This seems to me a rather simple and effective way to get to right-sizing… cool stuff!
I like to think about such things, thanks for sharing Maarten. Thinking about what’ll happen in a team with tasks in many different sizes. I saw teams having a good benefit of the flexibility in story points because they were able to use their average velocity (for them! 😊) during the planning to avoid dramatic overcommits.
When such a team has stories within the rage from 2-5 and will replace them with a 1 from your approach, they’ll lose sharpness.
How did you observe the switch on the estimation method in your teams?
The tasks became smaller, as the focus was right-sizing and not estimation.
Try it out, I believe your hunches are not grounded in reality but prove me wrong!
can you comment on your definition of cycle time? Is it from the first time it was discussed in refinement to production deployment? Or from when it was brought into the sprint from start to Done (and maybe not actually deployed to Prod)? Etc. I've definitely moved into the camp that uses anything but Story Points...but that's a really hard change for teams to make. So I really appreciate any sort of experiment to see if we can do better. One more question - is this really just a different way of estimating and planning using throughput? Basically, how many work items can we complete in a sprint on average.
And yes, it's just a fancy label and some thumbs up and thumbs down Roman Estimation story-telling to help make it more attractive than Story Points.
Yes fair point!
The moment we started working on it, after refinement, so it excludes the part where you refine it as in progress work.
However, around 80 percent was refined during Sprint Planning, so it would not affect the median much, but it would definitely add outliers to the average.
After a quick reading/scan of Nick's post, Escaping Story Points with Right-sizing, I assume that the time-box of 5 working-days is connected to the average cycle times below 4 working days and the median cycle time of 3 days or less. Am I correct?
Yes, that was the time-box we used, but you're free to deviate.
Interesting, is this created by you? :)
Yes, but it doesn't matter who created it, the only thing that matters is whether it works or not! :)
(And based on my experiences and what others have shared with me, it seems to work much better than Story Points!).