Undone Work in a Sprint

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.

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

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.

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.

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

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?

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).

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).

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.

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

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…

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

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

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.

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

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!

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.

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.