No done increment by the end of sprint
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?
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.
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.
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?
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.
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?
@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.
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?
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.
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'.
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?