Incomplete Sprints - what to do?

#1

Continuing the discussion from To estimate or Not to estimate:

Are we too nice to development teams, if we consider to handle incomplete sprints by discussing ways to improve? Shouldn’t we be hard in pointing at the agile principles, which provoke a potentially shipable increment at the end of a sprint and make this the criterion when to stop?

I would encourage to be more hard about following the principles, but also encourage to make effect of failures perceptible immediately. Not by stopping and giving in, but by overcoming them and have results to learn from.

#2

Curious questions of clarity…

When you say “sprint”, are we focusing on a strict Scrum methodology?
When you say “incomplete”, what do you mean?
What do you mean by “too nice to”?

The agile manifesto (and principles) mention the word “sprint” nowhere… what are you referring to by invoking the “agile principles”?

I ask these questions before sharing opinions as it’s always better for me to gain context before projecting. :wink:
That being said, I think I agree on your intent, but not sure about where you are suggesting the execution be directed to.

#3

If we are invoking agile principles, I would go towards “our highest priority is to satisfy the customer”. Is the customer unhappy about the ‘incomplete’ sprint?

We work with scrum, and try to keep our PO as up to date as possible about the work we believe will be done by the end of the sprint. In our case, I believe our PO is often too ‘nice’ to the team, which means that scope is renegotiated often towards doing less. This happens with so much understanding between the parties that there is a chance that the business pain is not felt that much at development.

I believe in a scrum environment if anyone needs to be less nice to the teams for the health of the company, it would have to be the stakeholders at the sprint review or the PO.

#4

I am not referring specifically to Scrum, even though I make use of the term Sprint.

Sprint is just the best term describing a planned increment. And that’s what I am looking at when I consider that something is not done at a specific point of time.

I consider something to be incomplete if shipping to customers does not work out for me.

Shipable includes the obvious technical feasibility (compile, package, deploy), but there is also no value in shipping something to a customer, which does not work for him. This is to be considered to be incomplete as well.

I feel that we are often too nice to allow teams to have their interpretation of agile.

Agile requires a common mindset and will fall apart if individual interests come into play. You need to be hard about and should not retreat from it just because you try to avoid conflicts.

I hope these answers make sense to you.

And now I am curious. Why is it important to be very precise on these aspects? I am keen to see you reply.

#5

I am not sure I really understand the problem. In my team the team does it’s best to finish the stories within the Sprint. Sometimes just a day or hours before the review it becomes clear that the story will not be finished. What do you propose to do? If you realize halfway through the sprint that you will have nothing finished at the end of the sprint you can always cancel the sprint and plan again.

#6

@hdietrich - I’m glad I asked questions of clarity, your responses helped!

Some people subscribe to “sprint goals” and I didn’t know if that was driving your question… it seems not though. It seems you are focusing more on “ability to ship” and related release goals.

1- I totally agree that the only measurement is “ability to ship” and “value to customer”. If this can’t happen, don’t ship. There is no gray area here.

2- I totally agree that you need to have your business completely aligned on this and not allow the team to interpret agile in a different way. DONE criteria can be a great facilitator in this conversation.

How this ties to your “sprint” or developent increment though is a property of your own environment. I’ve always pushed for 2 (or 1) week sprint interations… at that level, in the bigger enterprise software settings at least, very little is ready for ship. Our ship cycles are at the month and multi-month levels. We seek continuous flow over strict “sprint” boundaries.

I hope this helps, feel free to ask more questions…

#7

There is a big difference between halfway down the sprint and few hours before the review. I found it almost impossible to cancel a sprint and restart planning just few hours before we are supposed to be done. That simply does not work for me.

From my perspective there is no regret. A team has to learn how to handle it better.

#8

What is the result at the end of a sprint? Is there a definition of done in your setup?

#9

From my perspective there is no regret. A team has to learn how to handle it better.

It is not always the team’s fault. That is oversimplyfing things immensly…

#10

Acting based on principles always requires a kind of simplification.

It might not always be the teams fault if a sprint cannot be completed. The cases are rare even though.

I have supported my teams in becoming better in managing sprint goals and handling impediments. As soon as they have understood that they can take appropriate actions in a joint effort including product owner, development team, and scrum master, they feel much better about their plans. I would say they are much happier than before, as they gained self-confidence for themselves and gained a lot of trust from others.

If a would have been kind and would have accepted the argument, that it is not always the teams fault, we would have never got to that point.

P. S. important is to continue listening to the team. You do not want to be unfair. Valid argue always can lead into an exception from the principles.

#11

Yes! There is a definition of DONE at the card level… and at the release level (which has 2 levels… preview candidate vs. market release). As we are a complex global organization with a set of tightly intertwined apps/components… meeting DONE criteria at a card level in a sprint is not typically enough to ship it in a release until several build up and are coordinated across teams. (We have a core app that all other app’s leverage and ride on top of.)

#12

@kschlabach Are there code changes happening after the card level is DONE? I would also be interested to understand what is happening to bring it to the release level.

#13

Cards/Stories are shippable increments to facilitate internal customer coordination (incremental slices across teams). The combination of the cluster (think epic or feature group) is for the external customer. Sadly, things like penetration and performance testing also occur between card complete and release… (still maturing that part of our business and how it integrates).

#14

(Note, I have skimmed most of the comments. So I’m responding to original post.)

If a team intends to produce a Potentially Releasable Increment by such-n-such date (i.e. by Sprint Review if we’re talking of Scrum), AND if they do not achieve that goal then:

  • the data (i.e. facts!) illustrate that the organization (the team within its organization) is not capable of that amount of work in that amount of time.
  • I consider it an organizational or systemic problem. (The team didn’t fail… the entire organization has proven to be incapable of delivering x in y timeframe…whatever x was.)

Scrum encourages us to make decisions based on what is known and so I would expect the Scrum team to devise a more conservative Sprint Goal in their very next Sprint. And the next and the next…until such time they actually achieve a potentially releasable product increment within the Sprint and have no “undone” work.

#15

I’d argue there is only once condition in which it makes sense to cancel a Sprint – that is, when the Sprint Goal is obsolete.

Overestimating the team capacity is not a condition which makes the Sprint Goal obsolete – it simply makes it unachievable.

To mitigate risk, therefore, I’d suggest the team devise a smaller batch of work to do in their next Sprint – small enough to be truly achievable. Ultimately, until the team stops “over-committing” they cannot know their actual capacity.

#16

What are you doing if the results are not ready to ship at the end of a sprint.

I.e. I have asked teams to continue until they are done - means starting no new sprint before the previous one has been reviewed and approved.

I also heard from others, that they have isolated an overspill and created a new story for the next sprint from it.

#17

I don’t understand this… isn’t a team always in a sprint (except during review, retro, planning meetings in between sprints)? In the pragmatic sense, sprint boundaries are akin to mile markers on the highway… measurement points across distance to support data collection and projection. Even if you stop moving, you are still between mile markers. I’m confused… I’ve never heard of a team doing work outside a sprint.

Unless… you mean that you extend the existing sprint. I’m a strong advocate of not moving sprint boundaries to keep cadence and provide a chance for recovery (flush that mistake and try again with something more realistic). Going back to the beginning of the conversation though… maybe you mean “iteration” or “release” instead of sprint (when you use words like “sprint” we will likely assume the scrum aligned definition).

Also… not moving sprint boundaries allows cadence to be stable and organized in a scaled setting across the enterprise. In my current org… we have teams on a sprint cadence where there is a review almost every Tues/Wed/Thur (handles 6 teams, 2 week sprints), and this ensures our demo audience is aware and engaged.

Flow, Decoupling Cadences, and Fixed-Length Sprints
#18

I mean it exactly as I said it.

a) a sprinter will not continue with the next sprint right after passing the finish line - there is some recess
b) like the heart rate of a sprinter adjusts to the level of exhaustion, we should not try to keep an artificial cadence, which does not work

This might sound provocative, as it is not in line with the “scrum aligned definition”. But it is a more agile understanding by itself and thereby makes sense to me and others.

The goal is not to extend sprints. The goal is to adjust work to fit in sprints. Anyhow, for training this understanding the definition of “bring something shipable, whatever it takes” is a great instrument. It just takes some patience until teams become better.

#19

I took over a new-to-agile team almost a year ago, and one of the things we initially struggled with were committed stories that didn’t get completed in time. I let them get away with splitting the remainder into a new story for a few sprints, and during that time worked with them to get better at grooming and proper story size. Wouldn’t you know it, they eventually got really good at chunking the work.

Then I started working towards #noestimates and things are getting really nutty!