Planning less tasks to take more issues if spare capacity is left later on
Hey there,
I see in my team a pattern that they are taking to the Sprint only safe amount of tasks.
As they say, it's better to take too little to drag something into the sprint later on than take too much and stay with things undone.
Should we evaluate tasks and in every case target for full capacity in point?
This looks like going safe hand but does it make a big impact if the tasks will be inserted into the sprint while there is some space left to deliver?
I would like to hear Your opinion on this.
Best regards,
Rafał
Planning Sprints in terms of tasks (or any type of unit of work) tends to be indicative of a feature factory, or an organization optimized for doing work, rather than an organization optimized for delivering value. Although this doesn't mean that looking at the work isn't useful, since it can be a good way for a team to understand if their goal is likely to be achievable. The primary outcome of a Sprint Planning session should be an achievable Sprint Goal.
Selecting Product Backlog Items for a Sprint is only somewhat related to the Sprint Goal. To craft an achievable Sprint Goal, the team will have to identify the Product Backlog Items that directly support the Sprint Goal and see if they believe that the work can be done within the Sprint, knowing that some work may emerge and other work may be learned to be unnecessary. What it means to "believe that the work can be done within the Sprint" depends on the tolerance for risk and uncertainty. A risk-averse organization may want to leave more of a buffer between total forecast capacity for work and work believed to be needed to complete the Sprint Goal.
Especially in these risk-averse organizations, there's nothing wrong with deferring the selection of additional Product Backlog Items until later in the Sprint. This is up to the team to decide. Having a list of all of the intended Product Backlog Items for a Sprint isn't an objective of Sprint Planning. As long as the team is delivering appropriate value within each Sprint and is able to effectively create and deliver upon their Sprint Goals, there are several ways that the team can choose to go about filling any remaining capacity in their Sprint.
Joining @Thomas on this one. Sprints are not planned to deliver a lot of finished tasks. They are planned to deliver an valuable increment that satisfies the Sprint Goal. The Sprint Goal is the item that drives what work is done in the Sprint. If the Developers feel that they can achieve the Sprint Goal and still have some available time to do work, they can choose to pull in additional Product Backlog items either during Sprint Planning or during the Sprint. However, they could also use that extra capacity
- to refine stories in their Product Backlog
- educate themselves on technologies that they have recently started to use
- educate themselves on technologies that they feel could be useful to implement
- spend time getting to know each other better to build comradery
- work on items identified in Retrospectives to help improve their ability to work together and deliver value
- ...
The Scrum framework does not identify a Sprint as a way to make sure that every Developer is coding all of their available time. A Sprint is a way to help Scrum Teams focus on delivering incremental value to the Product that they support. It is to help the Developers ensure that they are working on the right changes to the Product so that the stakeholders will be able to get incremental improvements/additions. Sprints are not time management or project management artifacts.
Thank You both Thomas and Daniel for Your answers.
I see Your point here and I understand this.
Yes, I would say that we are struggling with defining a clear Sprint Goal that would describe reaching of an increment.
In most cases it ends up with selecting few, the most important PBI's, as a Sprint Goal.
I'm new in the team that has it's own habits and I didn't find a way yet to direct it in this way.
In most cases it ends up with selecting few, the most important PBI's, as a Sprint Goal.
That isn't a Sprint Goal. It's just a subset of the work.
A Sprint Goal makes the selection of work coherent, and gives team members a reason to work together this Sprint instead of on separate initiatives.
Remember that not all of the work planned into a Sprint has to be essential to the Goal. Some things in the Sprint Backlog might need to be sacrificed -- in this complex and uncertain world -- if unforeseen events arise and scope needs to cut, while still allowing the Sprint Goal commitment to be met. In Scrum, that negotiable scope is where the contingency lies.
+1000 for Daniel, Thomas and Ian. I would add here that it is far better situation when the team plan with constraint in mind to finish things within Sprint timebox, than live in a scenarion with a lot ot things started but not finished. Even if you struggle to craft a Sprint Goal, you at least have the luxury to tackle it and think about the concept, as you are not hounted by not finished work that often may be related to some promises.
To answer directly your question: No, IMHO you should avoid thinking about capacity utilization at all. If it happens that some team members have slack time, spend it on backlog refinement, helping others, tech debt, self-improvement, etc. In the long run it will pay off order of magnitude more, than if you always fill that slack with more "work" to do.