0

Asking a Scrum Team to deliver valuable shippable increment each Sprint leads to reinsurance - team members will put additional time/Story Points in their estimates, thus reducing TTM (Time To Market).

Of course a Scrum Master or Product Owner can say in Sprint Planning Meetings that the Sprint Goal is to complete 70% of the most valuable items from the planned Sprint Backlog, but in this case the team will not be commited to completing the remaining 30%.

Or the Scrum Team may choose to always reserve 30% of a Sprint as a buffer for unforeseen technical problems (risk management).

And what does it mean to business? It means that the TTM will NOT be as fast as it could be. And the fast TTM is one of the things for which Agile is appeciated. This is what my question is about.

So should a Scrum Team be asked or expected to deliver the Sprint Goal each Sprint?

Improve this question
4
  • 2
    I believe there's a flaw in your logic, as I don't understand the rationale behind "team members will put additional time/Story Points in their estimates.".
    – Tiago Cardoso ♦
    Dec 13 '20 at 13:19
  • @TiagoCardoso Making so they reduce the amount of work they are taking for the Sprint. And thus they have more chances to complete this amount of work.
    – Daniel
    Dec 14 '20 at 18:46
  • The flaw seems to be still there. There's either a mistrust on the development team judgement (they will commit to less than they can to have some slack time) or there's indeed unforeseen technical problems and thus the reservation may be indeed required. If the former, then it'll be pretty challenging to be agile with such attitude within the team. If the latter, then the team is right in not committing to the other 30%.
    – Tiago Cardoso ♦
    Dec 14 '20 at 23:28
  • It IS challenging to be agile when you are working in customer software development business.
    – Daniel
    Dec 15 '20 at 9:05
2

Asking a Scrum Team to deliver valuable shippable increment each Sprint leads to reinsurance - team members will put additional time/Story Points in their estimates.

If you are calculating velocity there is no need to inflate estimates. The velocity will adapt over time and will reflect the team's genuine capacity to get work done. That is one of the key benefits of the story point / velocity approach.

Of course a Scrum Master can say in Sprint Planning Meetings that the Sprint Goal is to complete 70% of the most valuable items from the planned Sprint Backlog

The Scrum Master shouldn't be saying anything like that. They are not a manager of the team.

The sprint goal is typically defined by the Product Owner and is intended to give the team focus.

Should a real Scrum Team be asked or expected to deliver the Spring Goal each Sprint?

A Scrum Team will target achieving the sprint goal every sprint, but it may occasionally miss it. When they do it is usually a topic that is raised in the retrospective.

Improve this answer
4
  • 2
    The only thing that I'd add is that a Sprint Goal "communicates why the Sprint is valuable to stakeholders". I don't think that a Sprint Goal of "complete N% of the Sprint Backlog" meets that criteria. Even if the Product Owner wanted to define such a goal, I'd expect the Scrum Master to work with them (and the rest of the team) on crafting better Sprint Goals.
    – Thomas Owens ♦
    Dec 13 '20 at 13:23
  • I suppose you didn't get the point of my question. Scrum Team may choose to always reserve 30% of a Sprint as a buffer for unforeseen technical problems (risk management).
    – Daniel
    Dec 14 '20 at 18:55
  • @Daniel right, but if they reserve time for the unforeseen (which is understandable if it is based on the evidence of past sprints) then they would be aiming to complete 100% of the planned work for the sprint, not 70%.
    – nvogel
    Dec 15 '20 at 7:09
  • @Barnaby Golden Yes, but Time To Market will NOT be as fast as it could be. And the fast TTM is one of the things for which Agile is appeciated. This is what my question is about.
    – Daniel
    Dec 15 '20 at 9:10
0

Relative estimation is primarily for the team's benefit to help them forecast what can be done in a sprint. The points are whatever the team wants them to be. The team should aim to complete 100% of the sprint goal (or more) and experienced teams soon learn to judge how much they can take on per sprint. The team's judgement should carry more weight than velocity and points.

Improve this answer
0

Do you have any empirical evidence that the Scrum Teams you are working with are padding their estimates? If so, has this come up at a Sprint Retrospective? If it is happening, there are likely to be bigger issues, perhaps organizationally, that can be addressed.

Going to the Sprint Goal, the November 2020 Scrum Guide "communicates why the Sprint is valuable to stakeholders". A Sprint Goal that is "complete 70% of the most valuable items from the planned Sprint Backlog" does not meet the Sprint Goal criteria. If the Product Owner and/or the Developers are having problems crafting a Sprint Goal, this is a good opportunity for coaching. There are some good resources out there for defining Sprint Goals, and the addition of the Product Goal in the November 2020 Scrum Guide may help.

Once you step away from the Sprint Goal as a set of Product Backlog Items and defined as a valuable outcome for one or more stakeholders of the product, there are no rules for how many Product Backlog Items need to be completed to satisfy the Sprint Goal. In some cases, the Sprint Goal could be accomplished by completing a single small-sized Product Backlog Item.

I try to encourage the teams that I work with to ensure that the Sprint Goal's completion doesn't require completion of all of the Product Backlog Items. Exactly how much buffer to leave depends on the organization. If there are many interrupts and overhead, it could be as low as 50-60%. In other organizations, it could be as high as 75-80%. This is on top of leaving room in the Sprint for refinement and making process improvements, which also need to be considered in the Sprint Planning session.

In the end, the team should be asked and, generally expected, to deliver the Sprint Goal every Sprint. When the Sprint Goal is not met, that should result in a good discussion of what went wrong in the Sprint Retrospective and the necessary changes to increase the chances of success in future Sprints.

Improve this answer
2
  • You seem to be collaborating with the customer on the basis of T2M contract?
    – Daniel
    Dec 15 '20 at 9:00
  • @Daniel You're going to have to elaborate on that, since I don't understand what you mean.
    – Thomas Owens ♦
    Dec 15 '20 at 10:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.