If it won’t fit within a sprint, get creative.
One area that causes concern among software developers using Scrum is the short sprint time boxes. Specifically, how can they develop complex algorithms in short bursts?
We’ve all heard that stories should be kept small so that each one can be fully implemented and tested in a single sprint. 4-week sprints will make it easier to meet that goal than 1-week sprints. However, 1-week sprints make managing the project simpler because there are more frequent checkpoints and fewer opportunities for the team to get off track.
Some teams adopt 6-, 8- or 12-week sprints so they have plenty of time to implement complex stories. This may seem like a reasonable approach but be aware that there are many ways for the team to get itself into trouble over such long sprint durations. Thus, managing the project will be more difficult for the Scrum Master and the Product Owner.
There are occasions when a major chunk of work must be done and there is simply no way to accomplish it within a sprint. This usually happens when something is being upgraded or replaced within the software. Here are a few examples:
- Rewriting a complex search and sort algorithm to replace an existing one. You could implement search first then sort but you may have to take away the sort function for a sprint or two. Not good.
- Changing a database model. If the existing model needs major revamping, making the changes, updating existing code, and migrating the data is unlikely to be completed in a single sprint.
- Converting to a new library or toolset. If you’ve ever been through such a conversion, you know that it can be quite an ordeal. Some deficiencies get fixed and new ones are introduced.
What can you do?
Several options exist for dealing with big changes and the one you should select depends upon your situation. Regardless of the approach, normal sprints should continue even if the number of developers is reduced. If you stop sending updates to the business users, you risk losing their interest, or worse, damaging the team’s credibility. Here are a few approaches to consider.
Create a Feature Branch
Branching the code is an obvious choice. The team makes all the necessary changes to the branch and checks the new code into the trunk upon completion. This means having what are essentially parallel development teams. One group keeps working on backlog items within sprints while the other tends to the big change.
Ideally, code in the feature branch should be checked into the main branch often to maintain build integrity. The undone code can be hidden or disabled (see below). The point is to periodically verify that the build is not broken rather than to wait until the end only to discover the new code cannot be merged into the production build.
Hide or Disable Features
New code can be hidden from the user or completely disabled using options within the build or a configuration file read by the software at startup. User interface elements can be hidden or grayed out. Functions (or classes) can be configured to return a null result or dummy data so that other parts of the system are not impacted.
In a similar vein, the team could implement the user interface for a feature (or whatever triggers the feature) after the logic is built and tested. Thus the feature is implemented but there is no way to access it within the software until the team is ready.
Write a Wrapper Layer
If the team is replacing an older code module with a newer one, they could add a layer of abstraction such that the existing software calls the wrapper and the wrapper decides whether to invoke the old or the new code. The wrapper can be controlled via build or configuration file switches.
This approach means writing some throwaway code but it may be better than keeping the business waiting for updates or taking the risk of breaking the software.
Options are good but consistency is better.
It’s nice to have a set of options for dealing with big changes. Having said that, there is no substitute for short stories, short sprints and continuous integration. Use the approaches above if you must but only after you’ve explained why accomplishing the work within the sprint time boxes is not feasible. I’ll bet that more often than not, the work can fit within the sprints. You just have to try harder. Have you used any other techniques?