Agile planning helps you manage and stay on top of any changes that come your way in a project while keeping it firmly grounded.
Regardless of the approach your team prefers, both methods require some essential steps to ensure you get your planning right.
Agile teams work in time-constrained iterations called sprints, which generally range from one to four weeks. They have a prioritized backlog from which they pick the work items for the next sprint. If some work items are incomplete when the sprint comes to an end, these are added to the backlog and the whole list is re-prioritized again. When your backlog is prioritized and up to date, deciding what needs to be done next becomes a lot less complicated.
When you begin any project, you should have a vision or a broad idea of how you would like it to turn out. In the process of incorporating new requirements, you might have to change your sprint plan or your release plan. That means that your initial vision may also change, right?
Actually, no. Imagine you set out to build a safe, visually appealing car with good road performance: the perfect vehicle for the working parent. Now, as you go about the development process, you implement design ideas that make it sleeker and engine technology that promises amazing speed. Along the way there are some compromises to be made—the sleek-looking design only allows for two seats and the engine with the best performance comes with a low miles-per-gallon average.
Now, you end up with a sleek car that can quickly take you from point A to point B, but that wasn't the only condition in your initial plan. You wanted to build the perfect car for the working parent and this is clearly not it. The description of your Minimum Viable Product (MVP), or the goal you set for the product in the initial stages, should largely dictate your product decisions throughout its life-cycle to ensure you achieve your goal.
At the beginning, broad ideas are captured as Epics. These are broken down into workable items only when they're taken up. This means the user story you're going to work on in the next sprint is more detailed than one three sprints away. The team's knowledge of and context for each decision changes with every passing day. When you progressively refine your plans, your team will be that much wiser when they eventually nail the details down. Even if you know that every plan is subject to change, a well-documented plan can fool you into believing everything has been thought of. Progressively refining our stories as you go along ensures that you look twice before dotting your I's and crossing your t's.
The Project Management Institute uses an "iron triangle" as a metaphor for project management: its points represent the three constraints of project management—Scope, Schedule, and Resources— and encompasses "Quality." The interdependent relationships between these three points in a project ensure you can deliver on your client's expectations if you have flexibility in any one of these. In an agile project, you have to change your scope rather than compromise your schedule, cut quality or splurge on resources.
Any developer worth their salt knows that cutting quality in the current sprint is only going to accumulate technical debt in the future. Common sense tells us that adding a few more developers to the team should help us catch up with the schedule but this is not so. Fred Brooks in The Mythical Man-Month writes that "adding manpower to a late project makes it later." The amount of time you'll spend training them and the time they take to find their stride can negate the benefits they bring to the table. At best, adding new resources to an ongoing project can be risky. Extending the schedule can seem like the least risky option for developers, but it's quite a big one for investors. A lot of work in the software development industry is contracted, commitments are made, and clients are invested. If Time and Cost are inflexible points on this triangle, that leaves us with Scope.
Changing a project's scope to meet a deadline usually means dropping some features you committed to. Now, if you have a prioritized backlog, this shouldn't be a problem at all. Say you have a list of 20 features for your ideal family car project, and it turns out you can only do 15 of them. If your features are based on priority, the engine, frame, and wheel chassis would be high in the top 10, to retain your core functionality. If you can deliver your top 15 features while adhering to the projected Time and Cost of your project, many would consider this project a success.
When you practice Scrum and work in time-constrained iterations, you pick a set of tasks you know you can complete within the sprint. To do that, you need to be able to accurately estimate the efforts required for each work item.
In agile teams, planning should be a group activity where all the members of the team come together to decide the amount of work that they can likely commit to in the next sprint. A fun way to do this is Planning Poker, a consensus-based gamified estimating technique. Each member holds a selection of cards with estimation point values (for example 0,1,2,3,5..). When the Product Owner reads out a feature or user story, a discussion of that item ensues and then each member selects a card representing the estimation point value they would assign that item. Then, all the cards are revealed simultaneously. People who chose high or low values are given a chance to justify their estimate, and the team repeats the process until they arrive at a single value. This becomes the estimate for that feature or user story.
A lot of us treat estimates and ETAs as commitments in our life. However, in project management, any estimate the team agrees on during the sprint planning meeting should be treated as just that—an estimate. These should not be held against developers when they get a little ahead or behind on their schedule. A deadline should come with a margin of safety and space for flexibility. It's a good practice to use both "estimate" and "deadline" in your project management language to get accurate values of both.
When faced with looming deadlines, managers sometimes whip out a favorite fix: overtime. When it works once or twice, teams tend to fall into the habit of working overtime until a point when the manager slowly starts committing to greater workloads, assuming overtime can cover it. If they keep this up, they'll find that their team starts doing less work even with the additional time that overtime buys.
According to Extreme Programming Explained, "Overtime is a symptom of a serious problem on the project... If you come in on Monday and say 'To meet our goals, we'll have to work late again,' then you already have a problem that can't be solved by working more hours."
When you've decided what you want to work on, and you've estimated the efforts required to complete it, knowing the capacity of your team helps you assess how long it would take to finish a certain amount of work. Understanding the pace at which your team works is vital to perfecting your plan.
Working on a product can be likened to running a marathon. Long-distance runners pace themselves over the entire run. They run a little harder up the hill and recover on the down slope. At the end, they accelerate and sprint at a pace that is not sustainable beyond the finish line. While this added speed cuts down their overall time, they would not have made it to the finish line if they had tried sprinting from the beginning.
This strategic pacing applies to agile planning as well. Every team has a sustainable pace that they can keep up indefinitely, and it's important to respect this pace in your team. You can stretch a little here and there to meet deadlines, but no team can sprint continually without facing burnout.
"Agile Planning" is a broad term and is used with different meanings at different levels in the hierarchy. These meanings could be sprint planning, release planning, theme planning, product planning, or portfolio planning. Regardless of the scale of your plan, your planning boils down to these three points: deciding what needs to be done, estimating the difficulty of the chosen tasks, and knowing the best pace for your team.
Like the trial-and-error approach that the agile culture advocates, agile planning is a skill you perfect over time. The right combination of listening, domain knowledge, people skills, and decision-making are vital skills for anyone in a team leadership position. Becoming good at project planning, agile or otherwise, is an acquired skill and the first step is to acknowledge how indispensable it is.
"Universally valuable, but desperately unfashionable, planning waits like a spinster in a Jane Austen novel for someone to recognize her worth."
—Alessandro Di Fiore,
Harvard Business Review
As hackneyed as it seems, the simple reason behind failures in business is: things did not go according to plan. This is possibly the best argument for agility in planning. Agile planning promotes actions that work over ones that should work. With smaller feedback loops and frequent assessments, agile planning encourages us to adapt to changes over following a plan.
When you assess your goals and adjust your strategy based on real-time data, you'll find your targets getting more realistic. Agile software development is not an isolated practice. It's most effective when it's utilized by the entire organization, through all stages of the workflow. An agile mindset has many areas of application, and planning is a crucial way to influence your goals.
We all start our work, any kind of work, with planning. Make sure it's a good start.