8 steps to kick off quarterly planning
How to use long-term agile planning to build great software
Going into another quarterly planning meeting at work, I realized that I too am working on a long-term project. I'm building a house. Building software and building a house aren't all that different – both are long-term projects where multiple teams need to coordinate with one another, and any homeowner will confirm, the project is never done. Improvements can always be made, something always breaks, and market trends always change. Without a plan, you're at risk for potential for blockers or a move-in date that's always two months away.
Where software development differs, and home building could definitely benefit, is the use of agile methodology. Agile allows multiple teams to respond to changes, quickly. So how can agile, a method based on frequent, continuous delivery exist with long-term, big-picture planning? Is it possible to create a realistic forecast over a long period of time, knowing that the one constant is change?
How long-term planning and agile work together
No matter what agile methodology you are using, kanban, scrum, or a combination, there's still a need to forecast over a long period of time, make date commitments, plan resources, and tie your work back to a strategic vision. In software, it's hard to paint a vision with disconnected tools, like Gantt charts, spreadsheets, and custom mixes of project portfolio management (PPM) tools. Or in my contractors case, his spreadsheet, email, and text message mashup becomes instantly impractical.
The key to long-term agile planning is keeping your project details and task estimates in sync with your roadmap.
Before we talk about dynamic forecasting solutions, let's talk about the steps to build a long-term agile plan using the metaphor of building a house:
Step 1. Start with the big picture.
Whether it's a house or a product, you need to define the vision and outline the strategic themes. Think of themes as organization-wide focus areas. What do you want to focus on over the next quarter, 6-months, year? Where do you want to spend time and resources? Performance, user experience, security, new competitive features (hot tub anyone?), or a combination of all these?
Of course, I wanted everything, but there's always those two pesky realities – time and money. Setting your high-priority themes will help you focus your time and energy to do a few things really well.
Step 2. Identify the big ticket items.
Once you've set your strategic themes, it's time to define the initiatives. Think of initiatives as high-level groups of work that span across multiple teams, projects, and feature-level work that contain many user stories. Your initiatives should all directly contribute to your strategic themes.
For example, to support the security theme, we'd need to build a new foundation, with sheer walls on the frame, solid-core doors, and double-pane windows.
Step 3. Break it down.
So what work actually goes into installing new, secure, windows? Break down the work for the larger initiative into more consumable pieces, like epics. This will give you a granular view into all the steps required to achieve your initiative.
For example, you have to remove the old windows, buy new windows, install them, improve with window experience with coverings. These pieces of work would populate your backlog.
This will help you with the next, most important step in this planning process: estimating.
Step 4. Get estimating.
After work is broken down into chunks, you'll need a rough estimation of time to make a roadmap. A roadmap is a plan of action for how a product or solution evolves over time. You need this to understand when big things will happen and in what order.
This is where the expertise of your contractor (or product and dev managers) really come in to play. By looking at similar efforts in the past, you can get a good idea of what it takes to complete each epic.
Because estimating requires knowledge of past efforts for similar epics, it makes it even more important to store your information in one place. That makes looking back much simpler and your estimates more accurate. My contractor relies on his experience, but what happens if he forgets, or if a differnet contractor has a different experience?
At a later date, you'll take the final roadmap to the team (developers, window installers, etc.) where they'll scope it out with even more accuracy.
Step 5. Create smart releases.
When using agile development, teams generally deliver a working piece of software at the end of each sprint as a release (or version). However, when you're long-term planning and roadmapping, you need to define some rough release points on your roadmap, so you can estimate release dates over the next quarter. Like "Outside of the house complete," which combines the secure window initiative, along with framing, paint, insulation etc.
Package the work items in your backlog with features that are similar, make the most sense together, or provide value as a whole to customers. And remember, releases are driven entirely by the scope rather than strict cut-off dates.
Step 6. Generate the roadmap.
Now you have an estimated backlog, releases, and teams with a velocity. The traditional planning triangle shows that a plan has three variables: scope (what you want to do), time (how long it will take to do it), and resources (who can do it). You have everything you need to create a realistic forecast, or roadmap. Finally, your contractor can give you an idea of your actual move-in date!
Pro-tip: If you're agile, your teams will already have a velocity. This is where you can use a tool like Portfolio for JIRA to take your estimated backlog, match it with the teams' velocity, and produce a realistic forecast for you to use as your roadmap.
Step 7. Share with the team and validate.
Take your new, shiny roadmap, back to your team and validate it. Let the team break down the epics into stories and give their best estimations for how long the work will take. Your roofers may have some scheduling conflicts, or the foundation company ran out of concrete, so it will take six weeks to order. Use these outside factors to validating your assumptions and make your estimates, and the steps needed to complete your epics, more accurate. You should run your roadmap by key stakeholders, as well, especially if their approval is needed to move forward on certain steps.
Step 8. Keep improving.
With agile, and homeownership, no project is ever done. Continuing to deliver value through incremental improvements is what drives innovation and a killer home. Use your roadmap to inform and optimize future roadmaps. Get customer, or your family's feedback, and keep testing and improving on a frequent and regular basis.
Download a summary of the 8 steps of long-term agile planning to help you in your next big planning meeting.
Put it into practice
Get serious about agile portfolio management
Connect business strategy to development reality. Explore Portfolio for JIRA
Coming up next
Watch & learn
There's something for everyone in our archive of agile-flavored webinars and presentations. Keep reading
On a related note...
Agile Roadmaps: Build, share, use, evolve
Going agile doesn't mean not knowing where you're going. It means being flexible about the path you take. Dive in