"1 day remaining" forever

Let’s say the team is working on some story and need to finish a task which is originally estimated to 4 days. Once the team starts working they continuously decrease the estimate until they reach 1. The task then remains on “1 day remaining” for several days – even though the team actually do work (and hard, too) on finishing the task. You ask the team what’s going on, why the task never reach 0, and the reply you get is “Well, things keep popping up that we didn’t think of which has to be done too in order to finish this task. We can’t finish the task unless we also handle those things.”. Let’s say you don’t only see this occasionally. You see it over and over again, Story after Story and Sprint after Sprint.

What is the problem? (Please leave me some comments below if you’ve seen this problem). I have some likely suspects:

Estimation technique
I.e. your estimation process. If you keep having this problem then you probably need to consider if it is because you keep missing something in the estimation. Maybe it is always the same “thing” that keeps holding the task up from being finished? Could you incorporate that “thing” as an item in a checklist which is always considered during estimation meetings? Do you have the right people attending the estimation meetings? Do you have someone with deep enough, and right, knowledge about the system and technical domain to give his/her input to the estimate?

Technical Debt
As a system ages, the shape of its code, architecture, design etc deteriorates – its natural, and every coder knows it. The problem is that the rate of decay is so much higher if the people working on the system continuously take shortcuts. There’s a saying that I keep coming back to; “The dirty remains long after the quick is forgotten”. Think of that “dirt” as taking a loan. Eventually you will have to pay it back, and in the meantime you will have to pay interest on the remainder. “Interest” in our world is in the form of us having to deal with problems when developing new things; things inevitably take longer because the system is so complex. Paying back the loan will mean having to take time to eliminate those shortcuts (that dirt).

If your team tends to stay on “1 day remaining” for ages then you’ll need to consider if the problems they have (the unknown stuff that appears) are due to technical debt. If it is, you’ll want to prioritize very high some efforts for paying back some loans. There’s a business reality out there so, most often is simply not possible to halt development for six months and have all resources work only on refactoring. But at least you can ask yourself; are we increasing the debt still as we build new stuff? And if so, why? Most likely the developers do not want to take shortcuts, but they are more or less forced to because of pressure (implicit or explicit) from stakeholders. You’ll want to look at your team’s environment and see if you can somehow remove the feeling of them not being allowed to take longer time to do things “right”.

A mechanism to emphasize this is to introduce a bullet to your Definition-of-Done: “Not increased technical debt”. It should mean that it is not OK for a task/story to be finished until the implementation is such that it doesn’t increase the technical debt. I.e. it WILL inevitably take longer to finish, but the shape of the code will be better than otherwise. Next step is to replace that bullet with the following: “Decreased technical debt”. That will mean that with every story that is finished there has been some effort put in to refactor (even if ever so slightly) what’s already there.

Formulation of User Stories
If your stories are formulated in a bad way then the team will definitely have a hard time finishing. Maybe the stories are too big? Maybe there’s too much detail and no room for flexibility? If your stories contain every little detail then you’re really back to waterfall again. You’ll spend enormous amounts of time writing specifications, leaving no room for the developers to think for themselves and no way for them to build it in any other way than what’s specified. And hence, it will be naturally hard to develop in iterations. The problem is that the flexibility of the scope has been lost. You essentially end up with a fixed scope.

“Fixating a scope”, to me, is OK. Wow, that’s a controversial statement. Let me try and explain what I mean. As long as it is done on Theme/Epic level (i.e. something along the lines of what’s traditionally called “Function Specification” level) – and not on Story level (i.e. not like a Requirement Specification), then it is OK for it to be considered fixed. If you have someone (e.g. a customer) ordering something (e.g. a feature or a whole system) then it’s OK for that person to really think through what he/she expects. It’s even OK if that is written down.

But as the feature(s) come closer to the development team then it is important that it (however detailed) is broken down into User Stories which are flexible enough to be implemented in iterations, so that you are able to deliver something working at the end of every sprint.

If you’re the Scrum Product Owner, then spend some time thinking about how the stories are formulated. Is the level of detail “just right”? Is there enough flexibility in there for the team to be able to finish it (i.e. without being extremely restricted to an exact certain scope)?

Badly overlapping User Stories
Obviously there’s a million ways to derive (Mike Cohn calls it “trawl”, by the way) User Stories from a vision of a feature or system. I’ve stated previously that I believe the approach should be to divide the feature(s) into verticals (we call them “slices”). Regardless of if you listen to my advice or not :-), you risk running into the problem with overlapping stories. Note that I do not mean “overlapping” as in overlapping code/subsystem: on the contrary, continuous refactoring is all about iterating and reiterating the same code over and over again. What I mean is overlapping functionality; the problem comes when you can’t finish a Story because it intertwines with other Stories, in a way that you can’t tell which story you’re really working on. That is a badly overlapping User Story.

If the team keeps remaining on 1 day, then you should consider if maybe badly overlapping stories is contributing. Try reformulating stories with this in mind. Can you think of other ways to write the stories? Think of the acronym “INVEST” as a rule of thumb; stories should be

• Independent
• Negotiable
• Valuable
• Estimateable
• Small
• Testable

Finished does not mean Complete
This is, I think, as much a result of all of the above as it is a fundamental attitude in the people working on and around the system. When a Story is “Finished” it doesn’t mean that what has been done is in any way “Complete”. I keep coming back to it: Continuous refactoring, iterative development – this is what it is all about.

When unforeseen problems appear and a team stay on “1 day remaining” for ages, can it be that they put the wrong meaning in the word “Finished”?

“Finished” should mean that the story is implemented in some way. It doesn’t mean that the implementation has to be perfect, and it doesn’t mean it needs to be completed and never again returned to. I’ll post a separate blog some day about whether or not this means increasing technical debt or not (in my opinion it does not).

This, I think, requires a change in attitude among the developers, the product owner and the customer/stakeholders. A sprint demo/review doesn’t mean showing Complete stuff. It means showing Stories finished. “Finished” as in “Done-Done”, yes. But that doesn’t mean that we don’t go back immediately next sprint and add, change or remove stuff in order to finish another Story.

Also, another related cause may be that the sprint is too long. The longer the sprint, the more and the heavier the feedback will be from stakeholders. The more seldom the stakeholders see the result of a sprint the more they will feel that they have to “get all the comments out there” and thereby the bigger deal the sprint review will be to the team. And the bigger deal the more it implies “Complete”. So, consider shortening the sprint length (a lot) and get the customer and other stakeholders involved much more often. It is a matter of building confidence between team and customer – confidence that the result in the end is what was expected (or actually even better).