We don’t plan, we’re agile
Wrong. Surprise! Good agile teams spend more time planning than do teams with traditional project management.
For many, this seems counterintuitive. Many think that a team designed for responsiveness to business changes and competitive opportunities would just get good at reacting to opportunities and new requests. Carpe diem, seize the day; that doesn’t sound at all like sitting down and making a roadmap or laying out daily tasks for the next two weeks.
“In preparing for battle, I have always found that plans are useless, but planning is indispensable.”
– General Dwight D. Eisenhower
More planning in smaller chunks
Agile teams plan more, and they plan differently. Agile plans are not for comprehensive documentation, not to eliminate all uncertainty, and not to avoid midstream course corrections in advance. They are for tight team alignment on the next set of work. The provide clarity appropriate to the distance to the next horizon, and take 10%-20% of the team’s effort.
Let’s look at three essential kinds planning for agile teams:
- Sprint planning
- Architecture planning
- Roadmap planning
Sprint plan
In the scrum framework, a development team works with the Product Owner to select and commit to specific results, an increment of potentially releasable functionality or product. This is called a “sprint goal”. If a team has two-week sprints, the team selects the amount of work that they can commit to complete in two weeks, from the highest priority items in the backlog.
Sprint planning turns the top items in a product backlog into a sprint backlog. Through the course of the sprint, this backlog is converted to done work. So how, during the course of those two weeks, do you know you’re on track to get everything done?
- Plan for each day to get something specific done, and then
- Each day, get done what you planned for that day.
That first step is done either before starting the sprint, or on the first day of the sprint. If you do this planning before the sprint, you have more certainty you’ll be able to meet the goal before you commit.
If something doesn’t get done on the expected day, you re-plan in the middle of the sprint, how you will stay on track. Potential re-planning activities ask and resolve questions like:
- What tasks need re-ordered with this new information?
- If we have an unexpected wait on one task, what other task should we start sooner to make full use of the time?
- Do we need to swap work between team members?
This is the real reason scrum has a daily standup — and these could be better questions than the typical status report: “What did I do yesterday? What am I doing today? What are my blockers?” If you have a daily plan, the team already knows the answer to the first two questions, unless you say, “hey we must re-plan this.”
Of course, every sprint needs to have some margins for additional activity and unexpected happenings. Most of the time, this available time is to look ahead to future activity, and resolve uncertainty in the product backlog. But sometimes, it gets used up dealing with the unexpected happenings within the sprint.
Always, always leave a bit of room in every sprint to handle a bit of re-planning and adjustments, and if that time isn’t used to re-plan the current sprint, use it to plan ahead for the next sprint(s). It’s great return on time invested, eliminating future problems so the team can stay productive.
Architecture plan
When building complex new systems or processes, sometimes more dedicated time is needed for architecture planning. This can mean an entire sprint dedicated to fleshing out a proposed systems architecture, followed by another sprint creating a roadmap to implement that architecture over the next 6-10 sprints.
“What?”, you say. “I thought every single sprint needed a potentially releasable increment of functionality or business benefit? I can’t release an architecture or roadmap and get immediate business benefit.”
This is true. And ideal. And it’s possible with fully mature, experienced agile teams with a history of working together. But sometimes — especially with new teams working on new initiatives — it takes some time to develop a shared head space, common vocabulary and common understanding of the destination.
Don’t skip this step. If the team doesn’t have a shared understanding of your systems architecture, make it so. For a new product or complex process rearchitecture, this can easily take a couple of weeks.
I’m assuming you’ve assembled a team of competent technicians who can do the work, but they don’t know the big picture up front. They may be working together for the first time. They must take time to get a shared understanding of the systems architecture.
Make sure every member of the team participates in the discussion. Get into arguments, friendly fights (okay maybe intense fights) over the right way to do this thing. Get the architecture down in a picture, a shared diagram and vision of how the moving parts fit together, how the flow will work when the whole thing is done.
You’re right, the team just lost a sprint worth of productivity, not releasing anything but a document or a medium-detailed architecture diagram. Trust me, the next many sprints will be intensely more productive with a well-aligned team who now have shared context for every upcoming planning (and doing) session.
Roadmap and release plan
For brevity, I won’t make a clear distinction in this post between roadmap planning and release planning. Let’s just say it’s all about “what’s next” in the product development, as well as “what’s next after that”.
Whereas the team does all the sprint planning, and usually the architecture planning, the Product Owner is the one doing most of the roadmap planning and release planning, with input from key stakeholders.
As mentioned in my prior post, having features and functionality queued up in advance lets business stakeholder relax. They can know that even if something is not being worked on now, it’s in the backlog, and being considered alongside all the other priorities for the product. The roadmap and release plan can make that visible.
For the team, this is an essential resource, to help them think ahead to what’s coming. While it’s important not to over-build a solution based on features that are down the road, there are many times that consciously or subconsciously the team will make subtle design and architecture choices based on what they know is coming later.
Wow, that’s a lot of planning
Some get impatient with this much planning. That’s understandable. We all like to get things done.
First of all, remember that 10%-20% of time spent in planning is not a waste of time; it’s normal. That means you should expect 1-2 days of planning every two weeks.
Compare this to a traditional product life cycle — run the real numbers in old school project management — this 10%-20% is really not as much as we think. Consider that the value produced by agile teams is far more business aligned with tighter feedback loops, and there is less waste and rework.
The greatest risk of this much planning is when the entire team or culture falls into a trap:
full team involvement in everything
+
discomfort with any uncertainty
=
the entire team going down every rabbit trail
How not to waste the team’s time
Once the broad architecture is established, you only need to involve the team in detailed planning for the immediate work — the current and next couple of sprints.
Use selected architects or team leads to “race ahead” and figure out some of the roadmap elements in advance. If the entire team has system architecture capabilities, you can at least send different people down different rabbit trails.
The certainty of planning (readiness for a team to commit to the work) can diminish the farther out we plan.
Consider a team planning out ten sprints in advance. The current sprint has 100% confidence — all tasks and user stories are understood.
Different teams break down features differently, but for this analysis, let’s say a bunch of related user stories comprise an epic. The team does detailed planning at the story level, and selected team members look ahead to future epics, which are broken down into stories over time. By the time a story is worked on in a current sprint, it is completely understood and detailed subtasks are lined up to do the actual work, as defined in the sprint plan. The next couple of sprints are planned well enough that, if started today, the work could get done, though perhaps with some risk. Further out, it’s less certain.
| Sprint being planned |
Level of confidence |
Refinement focus |
Planning Participants |
|
|
100% |
Story |
Product Owner + Team |
| Sprint +1 |
80% |
Story |
Product Owner + Team |
| Sprint +2 |
80% |
Story |
Product Owner + Team |
| Sprint +3 |
50% |
Story/Epic |
Product Owner + Architect + Team Leads |
| Sprint +4 |
50% |
Story/Epic |
Product Owner + Architect + Team Leads |
| Sprint +5 |
50% |
Story/Epic |
Product Owner + Architect + Team Leads |
| Sprint +6 |
20% |
Epic |
Product Owner + Architect |
| Sprint +7 |
20% |
Epic |
Product Owner + Architect |
| Sprint +8 |
|
Epic/Feature |
Product Owner |
| Sprint +9 |
|
Epic/Feature |
Product Owner |
Note that there is no formal role for “architect” or “team lead” in the Scrum Guide. This is simply one way to plan within an agile framework. Feel free to use whatever vocabulary make sense for your team, and adapt this to your situation.
Of course you’ll adapt, because plans change. But planning is essential.
Pulling well-planned stories
Well written epics and stories sit there, ready to go. When the team is ready to build the solution they “pull” the next stories. Because they were involved in planning the work, they can be trusted to complete the work they committed to do. And if they miss, they have a tight feedback loop to make a better plan and a better commitment next time.
This pull model is different than the “push” model of planning, with rigid milestones tied to fixed functionality. Work is not dictated to the team, it is prioritized for the team, and they pull into the sprint, before it starts, the amount they are ready to take all the way to done. Everyone likes to get things done.
Final note: YAGNI
If you’re ever wondering whether to over-architect, or over-plan, or even over-deliver and you’re considering doing extra work that doesn’t provide benefit any time soon, but might be useful down the road, but you’re not sure … remember this acronym and let it be your tie-breaker: YAGNI.
You Ain’t Gonna Need It.
Plan to deliver what’s next, plan your priorities, and plan well. You can even plan big. But remember, plans change. If in doubt about something that’s not the next most important thing: YAGNI.
