The Team moved all stories (except the last one) to “Done.” Quite a successful sprint that was! But in the next sprint, things didn’t go so well. First of all, the new software still had to be integrated into the main product. Then they had to create the release packages to release the new software to production. They suddenly realized they hadn’t planned for that.
So they adapted the plan, did the work, and went on with the new sprint. But then the bug reports started flowing in…
The key to good planning is to predict the future as well as possible. Without a crystal ball, we’ll need to learn from the past.
Definition of Done
In a talk to Google, Jeff Sutherland, co-inventor of Scrum, explains the evolution of the definition of done at PatientKeeper. First a feature was considered done when it was unit tested, but the stakeholders were not very happy with that. Then they said it was “done done” when it was system tested as well. They moved to “done done done” when it was acceptance tested by the users. It was “done done done done” when it was taken in production by at least four end users. But in the end they settled for “done done done done done,” if it was released to production for all the users they have. In Jeff’s words: “Let’s see if the phone rings in the next hour. That’s our demo. And if the phone didn’t ring, it was a great demo.”
It sounds odd to talk a lot about what done really means. After all, when it’s done, it’s done, isn’t it? But actually it is well worth it to spend some time on the team’s definition of done.
The More Done, the Better
Is your software ready when it passes all tests? Does that include integration tests, if it is part of a larger system? Was it tested by actual users? And does it really work in real life, on end-users’ machines?
Anything that is not part of your Definition of Done still needs to be done sooner or later. PatientKeeper invested a lot of time in advancing their definition of done as far towards the end user as possible. That way you exchange as much unplanned work for planned work as possible.
Done Includes Testing
If it is not practical, or even not possible to release to production at the end of your sprint, your definition of done should include as much testing as possible. Just unit testing is not enough; system testing or end-to-end testing needs to be done also. If at all possible, acceptance testing should be part of the sprint as well.
If you don’t do all levels of testing, the stories that were considered done will come back into a next sprint, because bugs or omissions will be found. When they come back then depends entirely on people outside your team, and the urgency of it as well. But in the mean time, the team moved on and might be working on something different.
Just like your definition of done, your test strategy might need a lot of work. Make sure you pay it the attention it deserves.
Test Driven Development
Test driven development means you write automated tests first, then implement the code to make the tests pass. Ideally, by the time the whole system is ready, you have automated tests for every bit and piece of it.
Apart from the fact that test driven development shapes your development in a good way, it will also make sure you have automated (regression) tests for your system. This makes it very helpful in ensuring proper testing is part of your definition of done.
If you find bugs later, you first add tests to reproduce those bugs, and only then fix them. Then you run all the tests again. This will make sure the bug is really fixed, will not return later, and you didn’t break anything else in the process.
Test driven development is a possible test strategy that may fit in well with yours. There is a lot of information about it on-line.
Don’t Plan for the Unknown
“I want you to keep detailed time sheets of all hours you spent on production problems.”
“Because if we don’t know how much time we loose, we cannot plan.”
“Because if we don’t know how much time we loose, we don’t know how much time is left for real work.”
“But it will show in our velocity!”
You can never predict the future (reliably, anyway,) but you can remember the past. In Scrum, the past is conveniently condensed into one number: your velocity. Your velocity does not only account for the work you planned to do, but also for the unplanned work you did. And that gives you the necessary bit of flexibility to tackle the unknown.
Dealing with Bugs
Even if “done” means released to production in your team, you still can’t be 100% sure a finished story won’t come back to you. However well tested, bugs might be discovered after the release. And bugs in production software usually have a very high priority.
Incoming bugs almost always disrupt your sprint. There is little you can do about it. The best thing you can do with it is handle it as all other unplanned work: make a sticky for it, put it on the board, give it the priority that is necessary (“should we drop everything of our hands right now or can we finish lunch first?”) and let the team pick it up.
The worst thing you can do with it is trying to ignore it. It will pile up and then it will kill your sprint completely.
Planned versus Unplanned
All those unplanned items look really ugly on your Scrum board. And they are not really prioritized, or sized, or handled top to bottom, as other items are. Why are unplanned items handled so sloppily in a neat and organized system like Scrum?
First of all: unplanned items are, well, unplanned. You didn’t plan for them. The fact that you even have a place for them on the board is already pretty organized. You have to make sure though that they deserve the status of unplanned: they should have high enough priority to be allowed to disrupt your sprint, and they should be small enough not to kill it completely. If the priority is not really high, put it off till next sprint. If it is so large that you cannot expect to finish it within weeks, but it has to be done now, kill the sprint and do a new planning session.
So now you have accepted an unplanned item in your sprint. What’s next? Do it now. Then it’s gone. The unplanned items area in effect is above all other stories on the Scrum board: it has the highest priority. If you handle unplanned items immediately, they have the least impact on your sprint.
Your Velocity Will Create Buffer Time
Handling unplanned items takes time; if you do a lot of unplanned work, you will do less planned work. In other words: the team’s velocity will go down.
Hopefully, the amount of unplanned work per sprint is more or less stable. It grows a bit after a big release and shrinks a little in the holiday season, but that is all difficult to predict (it’s unplanned after all.) Small variations don’t really matter; on average, your velocity will remain more or less stable.
If you have lots of unplanned work in one sprint and very little in another, that is a reason for concern. Where does it come from, and why does it come in bursts? This is a good topic for the retrospective.
If you have a lot of unplanned items on average, the variance between sprints will probably be large, meaning your velocity will jump up and down. That is not a good thing, because the predictability of the team will suffer. That is a good reason to keep the number of unplanned items as low as possible. If your amount of unplanned work is small enough, it will have little impact on your sprint. By using your velocity when planning a new sprint, you will automatically create buffer time for unplanned work.
To summarize: plan everything you can, but don’t bother about the things you cannot plan. They will be accounted for in your velocity.
Sharpening the Saw
“How do you generate the daily report?”
“We create that manually.”
“Why don’t you write a program to do that for you?”
“We don’t have time.”
“Why don’t you have time?”
“Because of all the reports we have to create manually…”
Even though you have a bit of leeway, large amounts of unplanned work should be avoided. But how can you avoid something that you don’t know yet?
Invest in Tools
Apart from bugs, another source of unplanned work is lack of automation. If you have manual tests, manual setup work, manual deployments, or manual database maintenance, the team will always be necessary to do these, and it will require a lot of time. Automated tools take even more time to create, but that will pay off later. Tools will make tedious work easier, makes it easier to repeat those jobs, and ideally will allow the team to let someone else do the work.
Writing tools is work that can just be planned in; create a story for it and do it. This is a form of sharpening the saw: don’t get caught in boring and time consuming work, if investing a little bit more time can get rid of it. Planning the creation of a tool is easy and predictable. Manual work is much harder to plan, as it can come back frequently.
If the amount of operational work is high, either because of buggy software, or because your tools aren’t mature enough, it may be better to split off part of your team into a new team, the fire fighters.
While they take care of all operational work, the rest of the team can work in peace. The fire squad’s main focus is to fix bugs and build tools; if they do that right, maybe they can be merged back into the team later. Seat the fire fighters team near the door of your team room. They will form a human shield for distractions that way.
Component Teams versus Feature Teams
Some teams don’t work independently, but work on a component of a larger system. They can do unit testing, but for system testing they depend on other teams: each component needs to be finished and the integration work has to be finished. Only then the system testing, acceptance testing and release can be done.
This is a difficult situation. It is almost guaranteed that bugs will be found, bits will be missing and help will be needed. But the team can never properly plan that, as the timing depends on other teams. So a lot of unplanned work will be generated.
Furthermore, this structure will lead to a lot of managerial overhead. For each new feature that is planned, the Product Owner of the team needs to deal with the Product Owners of other teams to synchronize the schedules. Instead of people being on the critical path, you now have complete teams on the critical path, for every single new feature.
A different approach for working in component teams is to form feature teams. A feature team is responsible for a new feature, and will change every component that needs to be changed to implement it.
Having feature teams will get rid of unnecessary critical paths. The team itself will do everything necessary to implement the new feature, and will not have to wait for other teams. It can also have a very advanced definition of done, because the team can consider the feature done when it is released to production. After all, they implement it all the way.
It does require something from the teams, though: they will need to learn something from each system; and they will need to work together with all other feature teams that might work on the same components. It will probably take some time before the teams work smoothly together. Automated testing is vital to get it right. But in effect, you are exchanging managerial overhead for a technical challenge. And by the time you have real feature teams, they are more or less interchangeable. This will reduce the managerial overhead to a minimum.
If you have component teams, the change to feature teams is a large reorganization and can be difficult to realize. A possible way to form your initial feature teams is to take one member from each component team and put it in each feature team. That way each feature team will have a component expert, so each team as a whole has the knowledge necessary to implement a feature.
The End User’s Done: Getting It Right
The Team moved all stories (except the last one) to “Done.” Quite a successful sprint that was! And the only reason the last story wasn’t done was because it was the Christmas Special Website. That could only be released to production on Christmas eve, and that was still six weeks away.
And since Done meant “released to production” for the Team, they couldn’t call it done.
Why is it so important to pay so much attention to the definition of done? Because your end users have only one definition of done: It Just Works. Perfectly. Anything short of that will make the end user unhappy, so they will come back and haunt you (or leave you for a competitor.)
So work on your definition of done, and see how far you can go. Buy yourself time by automating recurring tasks, and use that time to get rid of even more recurring work. And if it is possible, make your team responsible for the entire development track of a feature, from its inception to its release.
A good definition of done will not reduce the amount of work; that will remain the same. But it will keep the work together, instead of spreading it over the course of time. That will make it easier for the team to do it. Also, the better your definition of done, the more accurate your estimate is of the work that lies ahead of you, and that is what planning is all about.
In the end, all software becomes “done done done done done.” The question is how far ahead you could see it coming.