How Scrum Master forecasts delivery for a new project? E.g. after 3 months we will deliver this much work?
Here, the project is getting started from scratch and we don't have any historic data for reference. On top of that, the domain is also new to the scrum team.
Why not narrow the forecast to one Sprint, so evidence is gathered quickly, and coach the Development Team to make each Sprint forecast as best they can?
Beyond what Ian Mitchell said, why do you need to forecast so far out? Depending on your Sprint length, 3 months is between 3 Sprints (with 4 week Sprints) and 12 Sprints (with 1 week Sprints) - many organizations use 2 or 3 week Sprints, so it would be 4 to 6 Sprints out.
Do you even know if the project will continue that long? This is one of the advantages of iterative and incremental development methodologies. Often, the stakeholders may not fully understand what it is they need. Perhaps they have a few needs, and as you start delivering, everyone will learn what is capable and there will be new requests. Alternatively, they have a long list of things they think are requirements, but learn that not everything needs to be satisfied to solve their immediate problems.
I'd want to better understand why anyone needs a forecast for completed work beyond the next couple of Sprints.
Thank you Ian and Thomas for the reply.
@Thomas - I'd want to better understand why anyone needs a forecast for completed work beyond the next couple of Sprints.
Yes, we do this as a part of RELEASE PLANNING and there we make judgment about the delivery.
Why not narrow the forecast to one Sprint, so evidence is gathered quickly, and coach the Development Team to make each Sprint forecast as best they can?
@Ian Mitchell, this is a valid suggestion from the perspective of a scrum master coaching the team, however, could you clarify if it should be the scrum master who forecasts delivery or should it be the PO?
A forecast of work, sufficient for exactly one Sprint, is made during Sprint Planning. The forecast is a Sprint Backlog of work. Which of the Scrum roles are responsible for making this forecast?
A forecast of work, sufficient for exactly one Sprint, is made during Sprint Planning. The forecast is a Sprint Backlog of work. Which of the Scrum roles are responsible for making this forecast?
@Ian Mitchell, if I’ve understood right, you make a good point. It would be the Development Team. From that thought, if stakeholders participate, they could get delivery info from this event. However, isn’t it the PO who communicates progress to stakeholders in all other cases when the stakeholders may have not participated or if they haven’t inspected the artifacts?
If my understanding is not up to mark could you please advise what the gap in understanding is? Thanks.
A Sprint Backlog is forecast by the Development Team in conjunction with the Product Owner. Both roles have to be involved in the selection of work from the Product Backlog during Sprint Planning.
The Development Team would plan how that agreed work is to be implemented, while the Product Owner would be accountable for managing stakeholder expectations about the results.
Yes, we do this as a part of RELEASE PLANNING and there we make judgment about the delivery.
I haven't really seen much value in activities like release planning or quarterly planning. They feel like they exist to make companies and organizations feel safe when they are used to big up-front plans. More often then not, the plans that were made in such events turn into date-driven, fixed scope projects where certain functionality to stakeholders or become obsolete within a couple of Sprints of creating them.
I'm curious as to why you or your organization needs to plan releases. If you need sufficient notice before deploying an Increment to production, I'd look at your Sprint cadence. One of the factors in setting the Sprint cadence is the ability to synchronize between the team activities and business or stakeholder activities. If you get reasonably good at refining Product Backlog Items, forecasting the work you will complete in a Sprint, Sprint Planning activities, and then executing a Sprint, you can be very accurate in your forecasts of what work will be done assuming no changes to the state of the Product Backlog within a Sprint or two.
@Ian Mitchell, that makes perfect sense.
Just to conclude on the original post, the SM has a coaching responsibility only, forecasting is a joint effort by the DT and PO, DT is responsible and accountable for delivering the forecasted work and PO is responsible and accountable for managing stakeholder expectations.