Skip to main content

Undone Work in a Sprint

Last post 08:42 pm April 13, 2022 by Timothy Baffa
17 replies
03:06 pm July 19, 2012

Common Question:

The Sprint is over and some things did not get done. How do we handle that?


02:08 am July 20, 2012

I've got a blog post on just this question at http://www.richard-banks.org/2012/03/what-do-i-do-with-partially-comple….

To save you clicking through to the link here's the short version:
1. Unfinished/UnDone items are placed back on the product backlog
2. The Product Owner re-orders the backlog. Typically unfinished items end up at the top, but not always.
3. Do not resize the items to represent only the remaining undone work.
4. Do not split the story to represent what was worked on and what wasn't. An item is done or it isn't. There's no i-between.
5. Do not include any effort spent on the unfinished items in the velocity calculation of the current sprint. Velocity is a reflection of your rate of completion not your effort expended.

From an engineering perspective you should also consider approaches to development that will allow you to easily exclude unfinished code from the sprint's delivered increment. Two common approaches are the use feature toggles in the application and using source control with a branch per story pattern.


Anonymous
07:47 am July 20, 2012

I agree with Richard except on #3

I say re-estimate the effort to complete the item when it goes back to the product backlog. There are several reasons to that:

1. You want your backlog to be transparent
2. Velocity measures how much done software the team delivers in a sprint, so assuming the item will be completed the next sprint, only the left over part counts in the velocity of the next sprint
3. You want your product owner to easily assess the ROI of completing the undone item


01:16 pm July 30, 2012

Same thinking as Vincent's

3. and 4. are perfectly fine if they make sense in the given context. If it becomes a pattern then it could be a smell to be addressed in a retrospective.

In the end it is about delivering value and to work with the Product Owner.


07:27 am August 9, 2012

I'm with Vincent and Ralph here. I'd also add that there are many cases where the team realizes that a PBI can be decomposed into even smaller chunks of done work. For example, let's say that feature A can actually be broken down into chunks B, C and D. The team realizes it can deliver B and C to done, but not D. After talking with the Product Owner, they should return D to the Product Backlog (PB) and finish B and C. D then gets estimated and ordered along with everything else on the PB.

Remember, if we can take some work to done so it can be inspected, do it! Story Points, velocity and other estimation techniques are just that, estimation techniques. They are to be used by the team to determine what they can deliver.


12:39 pm August 9, 2012

I think Vincent, Ralph and Chad are right. I do agree that if the PBI is not DONE, then you can't claim it is, demonstrate it, etc. But work was done and we want to know how much work remains in the release. So, partially completed items should be estimated for work remaining. Otherwise, velocity is not meaningful.

I also totally agree with one branch per Product Backlog item worked in the Sprint. I wouldn't want to work any other way (but it's up to the team and the Product Owner).!

Scrum on!
Mark


06:23 am August 10, 2012

Mark,
I want to be clear that I am not advocating the use of partially done work. I am saying that there are cases where teams may be able to break a story down further into work that can be delivered as done. If this is not the case, then it should go back on the PB wholesale. The team may choose to re-estimate due to the new knowledge they now have.

What do you mean by "one branch per Product Backlog item?" Are you talking about a code branch? If that's the case, this is pretty dysfunctional and does not promote good collaboration and CI practices. Teams that I have seen do this (and there are many), typically spend a ton of time at the merge trying to figure out how everything is going to integrate. A better (IMHO) practice is the use of Feature Toggles, extensive test automation, CI behavior (notice I said behavior not tools) and the idea that the product can be shipped at any time.

Thoughts?


07:12 pm August 12, 2012

To avoid possible misunderstandings I just want to clarify the difference between "unfinished" and "undone" work. Unfinished work refers to Stories that weren't completed for the product increment according to the PO and DoD and what's discussed in this thread. However, undone work is any work that is required to release the product increment and must be transparent to the PO by capturing them in the Product Backlog as "Undone Work" or "Implementation Work" Stories (see also http://alistair.cockburn.us/Scrum+Guide).


09:54 am August 13, 2012

For those of us using Visual Studio and Team Foundation Server, I've posted the a similar request (for tooling support) on UserVoice (http://bit.ly/PjpAZL).


11:06 am August 15, 2012

Chad & Richard
I guess ideally if a story is not done during the sprint, everything should be reverted back to its original state so you can have a potentially shippable increment. This would include source code, scripts, documentation basically whatever was changed when working with the story. However, creating branches causes merge-hell and if the work is planned to be completed in the next sprint it's a lot of waste to revert the work already checked in.


12:31 pm August 15, 2012

Another solution would be to use a FeatureToggle. http://martinfowler.com/bliki/FeatureToggle.html

Here's a (.NET) project on github: https://github.com/jason-roberts/FeatureToggle


09:41 am August 21, 2012

I agree with most of the above, including Chris. In short, do something like what Vincent suggests, and make a clear distinction between "Undone Work" and "Unfinished Work." The term "Undone Work" was described in a previous Scrum Guide optional strategy as what Chris describes it as. In 2011, the "Undone Work" strategy was removed from the Scrum Guide. The removal of "Undone work" is briefly alluded to here:
https://www.scrum.org/About/All-Articles/articleType/ArticleView/articl…


09:42 am August 21, 2012

Maybe this link will work? (removing the s in https)

http://www.scrum.org/About/All-Articles/articleType/ArticleView/article…


09:51 am August 26, 2012

Chris,
Splitting hairs about "undone" and "unfinished" usually results in a dysfunction. We have a Definition of Done and work is either Done or Not Done every Sprint. The product is always in a "potentially shippable" state at the end of every Sprint so the use of other terms does not make sense. The PO can decide at any Sprint Review that the product and feature set are fit for purpose and want to ship. Certainly if more functionality is needed then the PB is ordered by the PO and more Sprints are performed. Similar to the forecasting we do every Sprint, the elements of a Release plan are also just a forecast. We should never count on them being set in stone.


06:30 am September 5, 2012

will the complexity of a undone/unfinished story be different to the complexity of the story before starting working on it? So why should the estimation changing when a story is started but not deliverable?
Maybe the estimation done in planing was wrong and this came clear after starting the work, but than you should redefine the story together with the PO?


regards



Carsten


07:24 pm September 12, 2012

Technically any Undone work (ie. work that is required to release the product increment) could be considered a dysfunction because if the PO decides to go live then it should technically just be pushing the "Go Live" button. However considering from the PO, management and stakeholder perspective always more needs to happen to Go Live. Just consider activities like technical QA/QC gates & transports, data migration, communication, training, handover to support & maintenance.

So my suggestion would be to introduce a "Definition of Go" similar to Definition of Ready and Done. DoG defines the incremental release state and allows identification of Undone Work until "Go Live". It's the Go-Go between the Scrum Team and their project stakeholders including management, support & maintenance teams, operations, etc. It should not be limited to what the Scrum Team is required to do (eg. technically deployment) but include all other incremental release aspects of comms, training, etc. that the Scrum Team is dependent on.

Overall, the DoG:
> defines the incremental release state of complex products in a complex environment
> makes Go Live (work) transparent for the Scrum Team and project stakeholders
> allows for inspection & adaption!


04:08 am April 13, 2022

 

I think we should avoid this kind of thing as much as possible and reduce the rate of work not done in each sprint.

As friends say about undone work, we have a concept called undone sprint.

Why is undone sprint dangerous?

Scrum is an experience-based framework and is one of the most important manifestations of the feedback cycle experience. Scrum events such as Sprint itself provide the opportunity to publish what we develop or improve in a short period of time for our customers and end users of the product.

If the features or changes that we planned in the planning session are not done at the end of the sprint, we will have to disrupt the release cycle of new aspects of the product and not release the unfinished ones. As a result, the feedback cycle from the customer is disrupted and the learning rhythm based on team experience is impaired. In other words, without the feedback of our users in recognizing the accuracy and quality of what we have provided as product features, we will have errors and lack of accurate information to decide future actions.

Also, insisting on this procedure in many cases increases the volume of undone works and leads the product to the downfall of users and failure. That's why undone sprints are so dangerous, even more so than technical debt.

Community Verified icon


08:42 pm April 13, 2022

I would actually take the opposite position on your closing statement.



Incomplete work at the end of a sprint is undesirable and can delay feedback loops around affected feature development; however, technical debt creates a similar feedback loop delay but can be much more frequent as it is usually code or process-based.


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.