Thinking in sprints: setting and communicating dates with Agile

“When” often is the word product development teams fear most. When is the release date for this feature in development? When is that feature a customer asked for scheduled on the roadmap? When will that nasty bug one of your investors discovered, be fixed?

Giving a confident answer to the question “when?”, is one of the objectives of making a plan. But, in the age of Agile development, is making plans and communicating dates still relevant? After all, two of the most common myths about Agile are:

• Agile = no planning, or
• Agile is incompatible with longer-term planning

It would be easy to dismiss questions for “when” with referring to being Agile, or with lectures about how long-term plans are doomed to fail. These are of course valid points, and they have been covered and proven in detail elsewhere. But the ones who ask for dates still deserve an answer. It’s important for Marketing and PR to plan release activities. (For example by activating press contacts or planning an on-stage announcement at a conference.) It’s important for the business development team to set expectations with your customers. And it’s always helpful to keep your investors happy. (Especially the ones who use your product.)

So how do you a) set and b) communicate product release dates in an Agile context? It’s quite simple: think and communicate in sprint granularity only.

Communicating internally in Sprint granularity

When you need to set a release date, instead of saying “October 13”, say “Sprint 19”. (In the appendix of this article we explain how to make this really easily understandable to everyone in your company.)

For far-out dates it’s often best to be less precise and, if possible, just target the calendar quarter. For example:

• for the current quarter: communicate sprint numbers as dates.
• for the next four quarters or so: communicate the quarter.
• anything beyond that: just communicate the year.

It’s really that simple.

Planning and estimating in Sprint granularity

The simplest and standard way to do longer-term planning in Agile is using your velocity, i.e. the number of story points or tickets you complete each sprint. I recommend the book Agile Estimating and Planning by Mike Cohn, but the gist of it is simple:

• estimate tickets in story points
• track your velocity
• to estimate a release date for a feature: estimate it’s size in story points. Divide it by your Scrum team’s velocity. Voila, you got the number of sprints it will take to complete it. (You may need to account for working on a few efforts in parallel.)
• issue management systems such as Jira these days also have automatic calculations of that sort for Epics and releases.

This simple type of back-of-the-envelope math can be surprisingly effective and precise.

Communicating your roadmap to customers

A product roadmap helps product planning. And it helps aligning and coordinating teams and their work. But it is also an important tool for business development. As highlighted in the introduction, customers often ask for new capabilities. It’s helpful to equip customer-facing teams with information to answer such questions. You wouldn’t typically share your long-term roadmap with all your customers, but you can set expectations on particular initiatives. For example:

• Confirm if something is on the roadmap or not at all. (Outside product strategyfor example.)
• Timeframe - give high level indications like depending on where an item is on the roadmap: “it’s on the roadmap this quarter”, “later this year”, “not earlier than next year”

Additional thoughts

Most people would agree that a typical one- or two-week Sprint passes pretty quickly. If then you break down a quarter or a year into its number of sprints, you will notice that it is a really nice unit of size to “grasp”:

• 1 calendar quarter: about 12 one-week or 6 two-week sprints, respectively.
• 1 year = about 52 one-week or 26 two-week sprints, respectively.

So you have at least 6 major release slots in a quarter or 26 n a year for two-week sprints. That’s by far enough, even for fast-moving companies. At the same time, these are still “handy” numbers.

Finally, even when doing a longer-term product plan, it’s wise to stay true to the agile manifesto preferring “responding to change over following a plan”. Simply adapt the plan and sprint-granularity dates as you go. It’s in fact much easier to keep track of changes of the sort Sprint 29 -> Sprint 30, rather than October 25 -> November 6.

In shipit, all the product roadmaps are by default broken down in Sprint granularity. This means, employing the above approach is made really easy.

Appendix: a few tactical details

• Sprint naming: it’s best to use a simple naming and numbering of Sprints that is easily understandable and/or listed somewhere. One approach that works well is to name Sprints after calendar week numbers. If you run 1-week sprints each Sprint easily corresponds to the calendar week number. For example, Sprint 41 or Sprint 19-41 refer to the calendar week 41 (Oct 7-11 2019)