Sprint planning - client would like to add more important stories than the capacity allows. How to explain client that is not possible?
Hi All,
I have the following case:
My team consists of 3 developers and 1 QA. Sprint is 2 weeks or 10 working days. One of the developers will be working 7 days. I calculated that the sprint capacity is 296 hours - 4 people 8 hours per day = 32 hours -> or 3 people 80 hours/sprint = 240 hours + (1 dev * 56 hours/sprint).
My question is how to calculate the estimated stories included in the sprint and how to explain to the client that it is not possible additional stories to be added to the sprint?
Thanks in Advance!
Best Regards,
V
My question is how to calculate the estimated stories included in the sprint and how to explain to the client that it is not possible additional stories to be added to the sprint?
Why would you do that, and why would the client care?
The point of a Sprint is to meet a Sprint Goal which mitigates a significant risk or uncertainty. It's up to the Developers to estimate their Sprint capacity, so achievable goals can be identified and then accomplished.
Although potentially helpful for the team, the capacity estimations are not particularly relevant for communicating with the stakeholders.
The stakeholders must understand that the Developers and the Developers alone control what work goes into a Sprint.
The Product Owner, acting on behalf of all the stakeholders, is accountable for ordering the Product Backlog. All the stakeholders need to respect any of the decisions made by the Product Owner.
Sprint Planning can be viewed as a negotiation between the Product Owner, representing the various stakeholders, and the Developers. The Product Owner wants to maximize the team's value delivery throughout the Sprint. However, the Developers are under various constraints, including their time or capacity to take on work, their knowledge and skills (of the domain, the tools and technology, and the product under development), the quality and levels of technical debt in the product, and more. Figuring out what can be done and what makes the most sense to do is a key discussion at Sprint Planning.
The stakeholders should be more interested in the Sprint Goal, which represents the value proposition that the Developers are committing to achieving within the Sprint, and how that Sprint Goal moves the product closer to attaining the Product Goal. They should trust the Product Owner to represent their interests and balance the competing interests of various groups when collaborating with the Developers along the way.