Workshop technique for estimating large work items (collection of User Stories) for project planning
I'm looking for a workshop technique on how to estimate features/themes/epics, or any large collection of User Stories without estimating each story itself.
Let's start with that we develop a large Scrum project for a client. Now we are in the unfortunate situation where there is a fixed deadline and the C-Level of the client expects a certain feature set to be available until the release. Gut feeling says the scope is too much so we want to provide an estimate of what could be ready until the release and what might be developed afterwards. This information would be necessary for them to arrange the market communication accordingly.
A prioritized list of these high level features exists. We typically do estimations using Planning Poker based on User Stories but I assume this will not work out on a higher level.
- Did you facilitate a workshop to estimate this high level work 6 month into the future?
- What method/technique did you use?
- How much detail should go into the description of the single items? They can not be discussed as in the Backlog Refinement.
My current idea: Affinity Estimation where the reference bucket size would be something in the scope of half a sprint.
I'm open for suggestions.
Have you had a look at what Liberating Structures has to offer?
Let's start with that we develop a large Scrum project for a client. Now we are in the unfortunate situation where there is a fixed deadline and the C-Level of the client expects a certain feature set to be available until the release.
Can you clarify why Scrum is being used for this, exactly? What purpose are Sprints expected to serve?
@Scott: I got through the list of routines recently to find a way to spread information so that it is understood not only heard. I'll definitely have a look at them again. However, I see them more as methods for problem solving. Can you point to two or three you would see as a setup for an estimation meeting?
@Ian: Scrum is used since it is the framework the dev team and whole company is most familiar with. Sprints are more or less used to gather feedback of the current state of the application and changing features accordingly. On the other hand there is still a high amount of (user validated) Must features. These are the ones we should estimate to adapt the roadmap and give a better answer as to: This will make it into the release, these are still unclear and those will be definitely coming afterwards.
Sprints are more or less used to gather feedback of the current state of the application and changing features accordingly.
How is feedback being obtained? It doesn't sound as though the client is receiving product value iteratively and incrementally, so that evidence-based forecasts can be made.
1-2-4-ALL seems like a good choice, but so do the options listed on the link you provided.
Fixed scope, budget, and timelines didn't work in waterfall and it doesn't work in Scrum. You cannot fix all three sides of the iron triangle. You can have a fixed 6-month date, just make sure you are transparent that the scope cannot be fixed. You can certainly be transparent in Sprint Review with regards to progress.
If you have any empirical data as to how much work your team completes in a Sprint you can look into using Monte Carlo forecasting. Again, there are no guarantees, but it can provide a forecast and likehood for completion.
Hello @Thorsten,
Sometimes we use "Affinity Estimation" or "Magic estimation" to provide an overview for stakeholders. As Chris said, there are no guarantees.
Here we are using a combination of "magic estimation" and "rate of error". This rate is calculated by the difference between previous estimation "magic" with the real estimation "planning poker". So you need to get the magic estimation and use same user story in planning poker to "calibrate" the rate. Then you can use it to provide a forecast with the range of deadline.
Usually we get the job done within the deadline range. Some projects close to the best scenario some projects close to the worst.
**Important to remember, agile projects take advantage from changes. In my option, try as much as you can to avoid set deadlines because we tend to follow the agreement even though the agreement doesn't make sense.
Thank you all. I now prepared the workshop as Affinity Estimation. This should give us a good understanding of the work ahead.
As a forecast I now dug deeper into Monte Carlo. This is a great tool to communicate in possibilities which I much more appreciate than just use Yesterday's Weather.
We do know that the current situation has anti patterns regarding scrum and agile working. We are in the process of inspecting how we got here, what are the symptoms and what cause them, so that we know how/what to change to get back on track.
If there is a a compulsory need for estimation, that is compulsory from management and you can't fight it for now,
one solution could be to use extreme quotation.
https://www.myagilepartner.com/blog/index.php/2019/05/14/extreme-quotat…
It is collaborative, with deleveloppers. You could have a rough idea, to begin to work with.
But before doing it you have also to see if management will not blame Developpers to hold on the estimations.
This is the most used trap.