One point of friction that comes up when working in agile software teams is how much up-front planning to do vs. planning exactly one sprint at a time. As an engineering leader, I have come to believe that a lack of up-front planning is a consistent root cause for failed, over-budget, or delayed projects with agile teams I have worked with. Teams consistently push back on the idea of planning an entire feature up-front with the claim “This is waterfall. ” I have come to the decision that agile teams should plan the entire scope of work until they deliver to customers. There are many cases where a release is delivered to customers at the end of the sprint, or multiple times during a sprint. If you are incrementally modifying a feature that is already live with customers, or are co-creating the feature with an internal stakeholder and are discovering what they want in real-time then planning a single sprint at a time makes a lot of sense. You don’t waste any energy planning work that changes with new information. You are truly agile and can change plans. It’s a powerful concept and it’s easy to see why teams that do it well get so much energy from it.
So why do I say that my teams should plan multiple sprints up front? Because our sprints and our iterations are different. The sprint is a hard 2-3 week cadence that gives us frequent milestones to measure our progress and discuss changes to our delivery process. Our iteration is all of the work from discovery, design, implementation, through delivery. We haven’t completed an iteration until we learn new information from our customers that we can use to refine our understanding of the problem space. If we are working on a feature and don’t get a beta in front of customers for 1 quarter then we are on a 1 quarter iteration. As you move from delivering value to customers in a sprint to delivering value in a quarter or longer your business risk increases tremendously.
Big New Feature
As an example, lets consider a company that wants to add robust notifications to a complicated workflow system. When an event happens, send a slack message, email, page, etc. to a specified set of users. I have worked with companies that would take a problem statement similar to this, perhaps with some additional business context about why customers ask for it and what use-cases it solves for, and immediately hand it to a feature team to start implementation.
I have seen it play out over and over again in companies that have a strong bias toward quarterly planning. We talk about what the most important things are. We stack rank them. We hand work to teams as effectively as possible and tell the board what we are working on for Q2. At the end of Q2 the team has delivered a subset of the vision of the notification feature. They worked in an agile way. They delivered the most valuable pieces first. They delivered their committed tickets every sprint.
And the business considers it a failure.
They wanted more features. They don’t consider it complete enough for launch. They had expectations that weren’t met. Engineering didn’t set expectations with the business on what could be delivered in a timeline, or how long it would take to hit the minimum feature set to do the big marketing splash.
So where did we go wrong?
ROI vs. LOE
Under the hood, every company is doing a return on investment vs. level of effort calculation for every feature. How much ARR will the new feature provide? How many sprints will it take a feature team to deliver? If the conversation happens up-front engineering will be expected to provide an LOE estimate. In these cases you will be doing up-front planning to have an accurate estimate. You can decide how accurately you need to be for your use case and what planning you will need to do to hit your accuracy target. If the company doesn’t ask for an LOE calculation you should still understand what the expected feature-set for launch and project when it can be delivered. It is engineering’s job to provide context to the business about where their money is going and when they can expect a return.
As an engineering leader, you should plan enough up-front that you can provide a date on when you can provide a feature to customers. In an ideal case that is on your sprint boundaries. If you ever have a longer-term project you own the date and should be reporting it to the business stakeholders before you place the bet. It will save your team from executing excellently and having a failed project to show for their effort.