Skip to main content

No done increment by the end of sprint

Last post 01:17 pm August 4, 2019 by Chris Belknap
10 replies
10:55 am August 3, 2019

In my 2-3 years of Scrum implementation, this is the first time wherein our team didn't deliver an increment by the end of the sprint. I can name a number of reasons why we ended up like this but the one that I really blame is myself for I am the Scrum master.

Anyhow, have you encountered this scenario as well?

In the Scrum guide, I don't see any indication that you can't present undone work (untested), is my understanding correct?

What else do you think we should do in the sprint review?


11:06 am August 3, 2019

This is confusing - the team finished absolutely nothing over the course of the Sprint? Not a single Product Backlog Item met the team's Definition of Done and was integrated? I find it highly unlikely that the team, at some point in the Sprint, did not see that things weren't going well and make appropriate adjustments to make an Increment that was, in some way, better and more valuable than the Increment from the end of the previous Sprint.


11:28 am August 3, 2019

Hi Thomas sorry I forgot to mention that this was the team's first sprint. I also forgot to mention that 4 of our developers were newly hired. No PBI was done but yes tasks were finished (e.g. test case creation, test case approval, code review, etc)

 

Most of the lead developers said that it's only normal because we are a young team.


12:26 pm August 3, 2019

In the Scrum guide, I don't see any indication that you can't present undone work (untested), is my understanding correct?

Here's what the Scrum Guide tells us:

The Product Owner explains what Product Backlog items have been "Done" and what has not been "Done";

The Development Team demonstrates the work that it has "Done" and answers questions about the Increment;

In the Sprint Review, how transparent would it be if "undone" work was show to stakeholders? 

Are you teaching the Scrum Team about using a Sprint Goal? Was progress discussed in the Daily about meeting the Sprint Goal?

New Teams often have lots of challenges in their first Sprint; what insights were generated from the Sprint Retrospective?


01:06 pm August 3, 2019

The fact that it is a brand new team significantly changes things.

Personally, I think that coverage of the inception type activities is a huge shortcoming in Scrum. Many of these types of activities simply aren't covered or are only implicitly covered. Team formation is something that is entirely totally lacking, and organizational onboarding activities fall entirely outside of the Scrum framework.

I think that there's still value in having an internal Sprint Review to look at the work that was done and shows progress to the Product Owner. I would consider focusing more on the Sprint Retrospective over the next couple of Sprints, though. At the Sprint Retrospective, consider looking at how the team is forming, working agreements are developing, the team is formalizing their Definition of Done, and resolving any issues that come up.


01:06 pm August 3, 2019

No PBI was done but yes tasks were finished (e.g. test case creation, test case approval, code review, etc)

How many PBIs were brought into progress?


03:25 am August 4, 2019

@Chris

I totally agree with you. Stakeholders might get a notion that a lot has been done during the Sprint. On the otherhand, I don't want them to think that the team did nothing. Sprint Goal is not "practiced" in my organization. What's important to them is "work should've been done". 



@Thomas

I agree. Especially with a big enterprise. I experienced something similar with this but my prev team at least was able to finish half of what we committed. And yes Sprint Goal was still fulfilled. 

@Ian

All PBIs (user stories) are in progress since their sub-tasks are moving right now.


06:43 am August 4, 2019

All PBIs (user stories) are in progress since their sub-tasks are moving right now.

What are your thoughts about that and the rate at which work is likely to be finished?


10:49 am August 4, 2019

They will be able to finish maybe at least 80%. The thing is it' still not a "done" increment. best case scenario is an untested feature.


12:18 pm August 4, 2019

I would suggest you to start implementing a Work in Progress (WIP) limit for each tasks based on the team skillset so that from next sprint the focus will be more on Start Finishing and Stop Starting and by the end of the sprint you will surely have some items that are 'Done'.


01:17 pm August 4, 2019

I don't want them to think that the team did nothing. Sprint Goal is not "practiced" in my organization. What's important to them is "work should've been done".

Seems like an opportunity for a Scrum Master to uphold Scrum and teach the team about the benefits of having a Sprint Goal, and why outcomes are more valuable than outputs.

Why does Scrum require a "Done" Increment by the end of Sprint? Why is this so important and not optional?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.