All Sprint Backlog items are completed before the end of the Sprint

Last post 02:16 pm December 6, 2019
by Shiva Kumar Gosul
10 replies
Author
Messages
04:30 am November 29, 2019

Hi, comrades

Please advice, what are you doing when all Sprint Backlog items are completed, but there is 1 week to finish the Sprint? 

Of course we may take additional items from the Product Backlog, but these items will be not associated with the Sprint Goal. 

04:40 am November 29, 2019

looks like the team is under committing items they can do for the sprint (I am assuming that the phrase 1 week to finish is there is still 1 week left in the sprint).

Is this sprint 1 or new scrum team?

05:12 am November 29, 2019

No, we are "old Scrum team" and the duration of the Sprint is 3 weeks. But we've completed all tasks for 2 weeks. 

07:26 am November 29, 2019

Has the Sprint increment been released yet? If not, when?

08:21 am November 29, 2019

Does absolutely everything in the Sprint Backlog have to be associated with the Sprint Goal?

02:44 pm November 29, 2019

and why do U choose a 3 weeks SP length ?

07:42 pm November 29, 2019

Thanks for your answers.

The release will be in 1 month. 

Yes, all Sprint Backlog items are associated with Sprint Goal

Regarding 3 weeks, it is historically convenient for us :))

02:14 am November 30, 2019

Is their technical debt or other improvements the dev team could do? 

In the case your team has no technical debt, I would let the dev team work with the PO to pull in some new work.

The overal decision on what to do (new work/resolving td) should be with the dev team.

12:12 pm November 30, 2019

I see an opportunity!

The immediate situation is that it seems you're in a fortunate position, and if the team has already achieved what everyone expected, and if there is a focus on the impact of the team, rather than how busy they are, the team should experience a lot of freedom for the rest of the sprint.
You can discuss what the right thing is to do now. This could be taking some days of your holiday, so you're available when the organization needs you more, it could be working on a smaller initiative, a series of quick wins that would otherwise impact focus in other sprints, resolving technical debt or you could even try to overachieve on the Sprint Goal. Maybe there's another team in the organization, and they will appreciate you being able to help them for the coming week.

At your next retrospective, this might be a good topic for the team to discuss.

One thing you might want to consider is the effectiveness of your Sprint Goal. Does it give the team freedom to change plans? What would have happened if you had the opposite situation, and you realized during the end of the Sprint that you wouldn't achieve the planned work?

One example of a bad Sprint Goal would be:
Implement all of the specs for the user profile page

A better goal could be:
Make it possible for end users to manage their user accounts
This would at least allow flexible scoping, in that it might be critical that users can save certain pieces of data, but maybe other things, like saving a profile image, or updating their email address might be 'nice to haves' that you do if there is time.
If the team gets everything done in time, they might still consider whether there are further UX improvements they can make.

An even better goal could be:
Increase the proportion of our users who have filled in their date of birth by 10%
This could be better for three main reasons.

  • It conveys a very specific business need; maybe this is the only reason the team is being asked to build the user profile page, and so the team can focus on the work that is most likely to achieve the goal.
     
  • It is outcome-focused. Being outcome-focused will usually drive different behaviours, processes and decisions.
    For instance, it could trigger your organization to release multiple times per sprint, so that you can get customer feedback more quickly.
    If the team is striving to achieve an outcome, they may use the original plan as a guide, but if they find for instance that few people even find the profile page (maybe by releasing, or perhaps with user interviews, wireframes and prototypes), they might propose (and build) a better call-to-action. If users struggle with the chosen datepicker, developers might iterate on it quickly, e.g. within the sprint.

     
  • It is possible to overachieve.
    So what if you achieve your goal after 2 weeks? Maybe the right thing to do next is to try and get that percentage as high as possible.

 

12:18 pm November 30, 2019

If you have a 3 week Sprint, why would you plan to release in 1 month? What empirical value does the 3 week Sprint provide?

11:05 am December 6, 2019

If you have chosen 3 weeks of sprint then obviously a release also after 3 weeks. Should't add any stories for the current sprint. Team can work on new stories in Backlog itself but should't take it to release