Some of the big, age old questions around Agile software development are:
- How do you scale Agile with larger projects and organizations?
- Do you still have to plan work? How far out?
In moving through our Agile journey at Constant Contact, we have found that YES, there are better ways to do planning.
Where we are in our Agile Journey
The Agile transformation at Constant Contact has focused on individual team maturity as well as evaluating incoming business projects and opportunities. We have defined the “initiative”, which belongs to the portfolio level. Initiatives are then broken down to Epics by the product organization. This answered the “front loading” challenge of managing incoming work from a scaling perspective. At the same time the teams are now continuously improving their scrum practices, and are achieving predictability and velocity. All in all, we are making substantial progress in our Scrum journey. So what’s the next step?
- How do we forecast what a team or teams can deliver over the next 90 Days?
- How do we move from planning for one sprint to 5-6 sprints out?
Where we are heading – Long term forecasting
Refined team backlogs are great and we currently have all teams working one to two sprints out. However it is still challenging to develop long-term delivery forecasts that provide a broader view of things. This is a gap that we need to fill as part of our Agile maturation process. We researched various methods for implementing this, including Program Increment Planning recommended by the Scaled Agile Framework. Ultimately we adopted an approach recommended by cPrime for whole team long term forecasting. It is straight forward and allows teams to work through the process effectively and quickly.
Whole team long term forecasting process
The steps involved for whole team long term forecasting include:
❏ Backlog estimated
❏ Create a column on the wall. Label it, “Product Backlog”.
❏ Lay out 3 to 4 months of product backlog items (PBIs) using Post-it’s on the wall
❏ Ensure all PBIs on wall are estimated
❏ Product Owner (PO) outlines sprint by sprint themes or goals
❏ Create 6 columns across the wall. Label the columns with the next 6 sprint end dates.
❏ PO adds a theme or goal to each sprint
❏ Do a quick reality check of Sprint themes
❏ Development team uses fist of five team voting to answer the following:
- Do the themes make sense?
- Does it look doable?
❏ Dev team and PO collaborate to allocate the PBIs and other work over the 6 sprints
❏ Pull PBIs from the product backlog into the next sprint that they fit into. Use the PO’s goals for guidance.
❏ What is the average velocity of your last 10 sprints? What is your forecasted average velocity for the next 10 sprints?
(Pro tip: Use your previous 10 sprints average velocity as your next 10 sprints average velocity.) Rearrange the PBIs and sprints until each sprint has the right projected amount of work.
❏ Continue adjusting PBIs and sprints until everyone agrees
Long term planning in action
Richard Kasperowski and Michael Nir of cPrime did a good job of training teams and capturing the results.
We started out with many stories on the white board and the workshop guidelines, prepared by the Product Owner, who did an awesome job in planning, leading and facilitating the planning session.
The well-prepared product backlog!
The empty planning board showing six Sprints worth of planning ahead.
With some hesitation – we let the team interact and collaborate, taking stories from the backlog and placing them on the board and it worked very well.
There was a remote team involved in the exercise, and it was a challenge to figure out a way to engage them effectively in the process. Although we were able to partially engage them, we need to think of other options that could be more effective for next long term planning exercise.
The long range forecast board getting populated with stories from the backlog.
Interactions and discussions
Wow! – That right there is people collaborating around a physical board – yes we used JIRA as well – however there is something magical about moving those stickies.
Once the team placed the stories on the forecast board, we negotiated our Minimal Viable Product based on value, velocity, priority and technical dependencies.
And voila! Our long term plan is complete after 3 hours and lots of collaboration – great job everyone!!
Retrospective feedback on the long term forecasting exercise
- Good that we are realistic about the plan
- Everyone seemed confident with the plan
- Gives us a roadmap as to what to expect while in past it was Sprint to Sprint – what’s in store for us
- Doing this I understand how much we can do and how much to focus design big picture
- At least we known what’s coming down the pipe and can identify dependencies
- When I started it was – we didn’t know what’s ahead and now we have a plan for 3 months….great meeting
- Preparation was really good – I also liked – it required us to look at priorities! We had to re-prioritize since we couldn’t fit all upfront.
- We planned 6 Sprints – almost like we saved time – huge view of 6 Sprints ahead. Saved some time by doing this.
- Knowing the plan for 6 Sprints makes me feel good
We Would love to hear your feedback
How does your team or organization practice planning work in an Agile way? Do you do long-term planning? Why? Why not? Please comment in the section below!
If you’re passionate about creating great products, and are looking to work in a dynamic, empowering and collaborative organization, check out our open positions at www.constantcontact.com/jobs.