by Dov Rosenberg –
Don’t you hate it when you get in the “zone” on something you are doing and then someone interrupts you? Just last weekend, I was in the middle of thinking about cleaning out the garage, when my buddy stopped by to watch college football. All thoughts of cleaning the garage went the same direction as the empty beer bottles – in the garbage. Unplanned work has the same effect on software projects.
Unplanned work comes in 2 different flavors: defects found during testing and requirements that get changed in the middle of the project. Both of these can be dealt with – if you have a well run agile development team. You need to understand what is causing the unplanned work if you want to make your software projects less expensive and more predictable.
Contrary to popular belief – not all defects are caused by programmers. Granted, it is hard to have a defect in a program without someone writing code. In many cases, defects are written because someone doesn’t understand the correct behavior, the correct configuration is not in place, the wrong data is loaded, or the test was invalid. On a recent customer project, I did an analysis of 10,000 + defects over a 3 year period. Nearly 40% of the reported issues were NOT caused by programmers. Regardless of the ultimate root cause of the defect, it takes time from someone to triage each and every bug and decide what to do with it. This can be a significant time sink for an IT organization that further contributes to late/delayed projects and increased budgets.
Unplanned user stories are another source of scope creep that works to drive a project over budget and beyond the original schedule. Unplanned user stories could be the result of a seemingly innocent hallway conversation where someone asks to add a “simple” feature that will only take a few minutes. Another popular source comes from digging deeper into a planned feature and finding out it was more complex than expected. Unplanned user stories are like those weekend plumbing projects to fix your sprinkler system that result in 37 trips to Home Depot and the purchase of one of every different PVC connector ever made.
Plan for unplanned work
The power of agile development is the flexibility it provides in dealing with uncertainty. But to not turn your sprint planning sessions into an exercise in hope and prayers – it is important to plan for unplanned work. Every organization has a bunch of background noise that happens everyday in which the carefully laid plans get drowned in. The key is to understand the organizational dysfunction and recognize it probably isn’t going to change and adjust your sprint plans accordingly. Adding a “tax” of between 15%-30% to each sprint to account for the unplanned work allows sprint teams to not over commit in their sprint planning. This has the added benefit of helping get the work planned for done correctly without having to cut corners to meet a schedule.
Unplanned work regardless of its source can set up a cascade of increasing time spent fixing defects and a reduced time in developing new business value. The longer the pattern goes unchecked, the bigger the cascade effect becomes.
The graph shows the growth of numbers of defects over a few months and the decline of numbers of user stories that the team could complete. The defects are unplanned work that the team needed to focus on – taking away their ability to deliver new business value. Many of these defects were found during integration testing after the sprints were completed.
It is important to minimize the work in process leaving each sprint – otherwise you are building up an insurmountable pile of technical debt that will cripple your productivity. Other side effects include blowing your project timelines and budgets, exhausting your developers, and frustrating your business partners with your inability to deliver on your commitments.
