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?
Planning challenges
- 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 product backlog
The empty planning board showing six Sprints worth of planning ahead.
The empty planning board
Ready….collaborate!
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.
Great post here Peter! Thank you so much for this!
It’s been a while since you’ve posted this – I wonder if you were able to continue this method for more projects since? Any issues at all?
I was just reading this post ( http://kanbantool.com/blog/does-agile-work-for-short-term-projects-only ) where they claim agile will wok for long term project management, but I’m still not quite convinced. Is your experience a definite proof it’s worth the risk?
Nice One!
This is really cool!
I’m curious to know why the remote team could only be partially integrated into the process? Was it a technical limitation (aside from the obvious fact that they were not physically in the room).
If it was a white/black board issue.
Maybe there is a way to digitize the board for them to interact with the team. Someone from the team could monitor their input and be the sync between the on-site and remote team.
Hi there,
You have a great blog and I would like to say thanks for sharing!
Hi, thank you for this post I agree with you that The Agile transformation at Constant Contact has focused on individual team maturity as well as evaluating incoming business projects and opportunities. very useful information
I was the dev manager for the team doing this exercise so can address a couple of the questions.
Regarding remote engineers, the challenge was really around how to make sure they could clearly see what was happening and actively participate. Most of the remote engineers were connected via a fixed PolyCom whose camera they could control. They could zoom and out and pan the room, but they couldn’t always see what was happening on the board since people were moving around in front of it.
We did a couple of things: we took pictures of the backlog and the physical board and kept posting them to our group chat room. We also used an extra laptop to join the meeting and would train its camera on wherever the action is, walking around it as necessary. Team members spontaneously decided to do these things and the remote folks were very appreciative.
Regarding whether we are still doing 90-day planning, the answer is an enthusiastic YES!! Several scrum teams have had multiple ones by now. We have seen a lot of benefits which we just presented at an all hands meeting:
1) we are uncovering dependencies earlier so we can get items on other teams’ backlogs in advance rather than surprising them with unexpected work needed in a hurry
2) sprint planning goes so much faster since we know what we want to do in advance
3) we can give our stakeholders better guidance for when we forecast a feature will be delivered
4) the impact of adding new items to the top of the backlog becomes a lot more apparent to everyone. There is a domino effect that necessarily changes those forecast delivery dates mentioned above.
Also, we don’t usually have the full 3 months of backlog groomed before the meeting so we QUICKLY discuss each unpointed story and point it as 3.1 (small), 8.1 (medium) or 20.1 (large). The “.1” tells us that we still need to go back and REALLY groom that story, but the quick sizing gives us a decent idea of how big it is.
Hope this helps!