I’m spending quite a bit of time these days helping organizations implement Agile methodologies. As such I hear the same set of questions and see the same set of issues over and over again. One of the issues I see quite often is the “long sprint.” To explain what I mean by this I’ll use a hypothetical conversation with a Team Lead new to Agile.
Team Lead: “How do you deal with the fact sprint planning and reviews take so long?”
Me: “How long is long?”
Team Lead: “Sometimes a week!”
Me: “How long are your sprints?”
Team Lead: “Usually 3-6 weeks.”
Me: “How did you determine that 3-6 weeks was a good length?”
Team Lead: “Because we couldn’t spend 2 weeks out of every month not coding! We use longer Sprints to avoid spending so much time in review and planning.”
For those of you that are experienced in Agile, you should see a few problems here. For now, let’s just focus on the “long sprint” concept. The “long sprint” seems to manifest in organizations that are always sprinting. First off, this is in direct conflict with the name sprint. Sprints should be just that, a focused exertion of energy over a short period of time…2-3 weeks max. So how do we solve our Team Lead’s issue with spending too much time in review and planning and not enough time writing code? Enter the “Release.”
A Release is a means of building larger blocks of functionality in multiple Sprints. (usually 4-6) Some Agile methodologies (XP) implement this concept directly, others do not. (Scrum) There are many reasons to use the concept of a Release, a select few are:
- Some features just might not fit into a two week Sprint.
- Allow team to perform work in parallel to development. In general team members can do work other than sitting in sprint review and planning sessions. This is because these sessions are lighter weight and involve fewer people. You simply review implemented sprint functionality ensuring it meets the needs of the stakeholder and grab the next chunk of the prioritized Product Backlog. (ok, a bit more than that, but you get the point) These two sessions should not take more than 3 days.
- Reduce the overhead of delivering software to production every 2 weeks.
- Reduce the information overload caused by releasing every 2 weeks.
- Define a delivery pace more inline with that of the organization. (the rope in the Drum-Buffer-Rope of Throughput Accounting)
The next logical question is “Do we create a Release Backlog?” I agree with Mike Cohn in this case and would say no. I do however, use the concept of a Release Plan or Release Roadmap. According to Mike a Release Plan contains:
- Graph showing historical velocity.
- Prioritized Product Backlog. (including some big user stories, "epics")
- A predicted range of where we will finish. This should be either a date-range for a fixed-scope project or a functionality-range.
- Personnel assumptions. (Team members and availability)
- Velocity assumptions. ("we’ll go about half speed during December because of holidays and time off")
I would also add the following:
- A Vision Statement. (“We want to add the shopping cart functionality and connect it to PayPal”)
- Estimated Release Value as I discuss here.
Using the concept of a Release in Agile organizations can be an extremely effective way to increase efficiency through the elimination of waste. I will try to post more on this topic in the future. As always, let me know your thoughts.
Further Reading:
Extreme Programming Release Planning:
http://www.extremeprogramming.org/rules/planninggame.html
Mike Cohn on Release Planning:
http://blog.mountaingoatsoftware.com/why-do-release-planning
Mike Cohn on why there should not be a release backlog:
http://blog.mountaingoatsoftware.com/why-there-should-not-be-a-release-backlog
Kelly Waters on Release Planning:
http://www.agile-software-development.com/2008/02/agile-release-planning.html