When a team or organization decides to go agile, one of the key practices to follow is letting a backlog drive the rhythm and order of development tasks. Unfortunately however, many teams fail to understand the nuances of the backlog and that using it effectively requires strict adherence to a set of rules, or all the flexibility that can be gained with agile processes is lost. This post attempts to highlight some mistakes I’ve seen made on teams adopting a backlog that can be fatal for those that fail to heed them.
#1 – Starting the next sprint without communicating and getting buy-in from all parties
This one should never occur if you have read my previous post, or practically any SCRUM/Agile process, but it’s amazing how often it happens. Technical leads can assign tasks to the next sprint and communicate them to their direct superior, without that manager or resource also communicating them to the rest of the business. I’ve seen this happen where 2 weeks into the sprint executives are upset about their feature not being delivered in the current sprint. I’ve also seen this happen where folks higher up in the organization add tasks to the next sprint and commit the development team to them without giving the development team a chance to give their sign off as well.
It is absolutely critical that anyone who can make a decision that impacts the feature set, design, implementation, or testing of the software sign off somehow on the tasks slated for development in the next sprint. It’s preferable to have a document or approval somewhere since early agile adopters need to be held accountable to their commitments to see the process work, and improve their analysis, estimation, and scheduling skills as a result.
#2 – Calling sprint tasks done when they have not been tested
This one gets controversial since some teams feel that testing should be done for a feature in one sprint in the next, but I’ve found that if it is done this way it often leads to two problems. First being that developers tend to not test their code, figuring they have an entire sprint past that to find and fix bugs. Second being that developers tend not to involve QA early enough in the process. As the design of a feature emerges during a sprint, QA resources should be involved regularly at key decision points, so they can formulate test cases as soon as requirements or stories are agreed upon, even before they are built.
Inevitably, bugs will be found in code. So developers should have a percentage of their total workload for a sprint reduced to allow for some percentage of that time to be spent fixing bugs and communicating with QA. Optimally a sprint should include enough time for a tasks to be completed with test cases for each decision created just-in-time for each decision, as well as at least one round of full testing of the feature to complete. This also assists in determining at the end of a sprint whether work remains to complete it. In the case that it does, a new task should be added to the backlog to finish the work that is remaining. This allows the backlog to be prioritized such that completion of the task can be deferred if it becomes less important when the sprint concludes. This leads into the next point.
#3 – Failing to carry over unfinished tasks into the backlog
In teams just starting to adopt agile, many times they are coming from a prior culture of finger pointing and unrealistic goal setting that results in a protectionist mindset. Developers and managers first adopting agile will have a tendency to want to show all tasks added to a sprint complete at the end of that sprint. The thought is that if they don’t finish the tasks, they can’t show progress to the executives further up who may be skeptical of agile. Unfortunately, this is the wrong approach and sets a precedent for the unrealistic goal of having that happen all the time.
Part of following an agile process is providing transparency into problems with estimation, design, and planning and this can only be done if people are allowed to make mistakes and improve. A developer who fails to complete a task on time will learn to estimate better in future sprints if given the chance, or just learn to hide their failure better if forced to act as though their tasks are complete when they really aren’t. A developer who begins to implement a feature only to find it is more complicated than originally intended or the scope missed key things will also learn to do better design work if given the chance, or they will continue to do a shabby job at defining things if forced to act as though they can still meet the deadline for ill-defined tasks. For a healthy team following the backlog, it should be normal for sprints to end with some tasks incomplete at the end-of-sprint meeting. It is the job of the development manager to communicate this and the reasons for allowing it to his superiors.
#4 – Failing to revise estimates for tasks during a sprint
This is related to #3 above and also embraces the reality of the unpredictability of software development. When a task is assigned to a sprint without the waterfall type documentation such as requirements documents, screen mockups, class diagrams, etc. it is completely normal for a developer to discover that the original estimate they provided was too small to complete the task in that sprint. At this point there are a number of possible solutions.
If the task is determined to be much larger in scope than intended, it can be deferred to the backlog and flagged as requiring a re-estimate. The task on the top of the backlog that can fit into the current sprint for that developer can then be assigned to be worked on in its place.
The developer could also provide an estimate for the time it would take to scope the new work (not implement it) and upon completion of that task, work with their superior to determine whether that work can be completed within the sprint, or started in the next sprint depending on the cost of the design and/or discovery effort.
Lastly, the developer can also break the work up into smaller tasks, with accompanying estimates for each and placed back on the backlog, allowing the team to determine which of those sub-tasks is most important and can fit within the current sprint. This must involve all parties (see #1) to take into account technical dependencies.
#5 – Changing the tasks in the current sprint during development
It’s not uncommon for a team to start a sprint, only to have an executive attend a key meeting with a vendor or a salesperson close a big deal where the feature they just envisioned or sold is now the hot item in their mind. Without a backlog, the tendency is to shift all efforts to this feature. This can mean cancelling an entire project when done in waterfall fashion. With the backlog in place however, changes in prioritization that occur after the sprint has started must be placed in the backlog and prioritized accordingly, and not replaced or added to a developer’s current workload. There are several reasons for this.
First, the effort of understanding a feature prior to starting it, and optimally communicating with people to get information about it is lost when a shift like this occurs mid sprint. It tends to result in lost information that needs to be re-communicated when that task is picked up again. Also, it lowers the morale and rhythm of the team by not allowing members to feel “safe” when in a sprint that they can finish their tasks without disruption. Executives and development managers should feel free to go wild with great ideas for their software – but if it changes the current design or adds to it, those changes must go on the backlog. Even if there is an impact on the currently designed feature, that impact is easier to absorb as a future refactoring than the disruption to understanding, rhythm, and predictability afforded by the “lock-in” that the sprint’s set of fixed tasks pulled off the backlog provides.
#6 – Waiting until just before the next sprint to re-prioritize the backlog
Once you’ve read the above “sins”, you can see that a sprint is a highly organic activity. During the sprint, tasks may carry over to the next one, or the business’ needs may change. It is important that development managers continue to communicate with stakeholders to look at the backlog and regularly review it for correct prioritization at key points of the sprint. Whether it’s once a day, once a week, or halfway through the sprint – make sure you take time to look at the backlog. As the project is developed it is normal that insight to future tasks that haven’t started yet arise out of development of current ones. Capitalize on this and keep the backlog up to date as much as possible. If you don’t, you risk having the team wait for executives and management to make decisions on what’s coming up on the next sprint while it should really be underway.
#7 – Committing to release dates based on far-off estimated sprints
One cool technique I’ve seen involves creating a list of backlogs for sprints several cycles out. Let’s say you have a backlog containing 50 task, and you are about to start sprint #2. You determine that approximately 5 units of work (tasks, features, hours etc.) can be completed by your team per sprint. So you assign 5 units worth of tasks to sprint #2, #3, #4, and #5. With a little calendar manipulation it’s easy to come up with an estimated release date. But I should caution you strongly against doing so with this many sprints. As you add more sprints with estimated scheduled tasks, your ability to predict the release goes down in relation. So if you only have 2 sprints left to go, and your team’s burn rate is pretty predictable, you should be much safer in committing releases to the business than with a larger number like 5 sprints worth of work. This is simply due to the nature of unknowns that are found during the development of each sprint. I have found in practice it is not enough to simply come up with some blanket number (like 20%) to account for unknowns and apply that to all of the sprints. A sprint 2 cycles out may have a feature that when started is determined to take 3 times as long as originally planned because its true complexity wasn’t understood at the time it was added to the backlog.
Hopefully it is obvious by now that going agile does not mean razor sharp predictability, consistently hit deadlines, and zero scope creep. Rather, it embraces the reality of software development and favors planning for reality and building a team that operates with tools at its disposal for dealing with change instead of a set of unrealistic goals that sound great in a meeting but fall apart and cost both time and money in practice. The payoff is continually delivering tested, complete features with a little practice, and a team that knows how to adapt to any situation without panic.