Person 1: When is National Scope Creep Awareness Day?
Person 2: It’s actually National Scope Creep Awareness Week now.
At work, I’m part of Agile teams that include a Project Manager, Scrum Master, and Engineering Lead, all of whom have a voice in the plan. We all work toward the same sprint goal, and we all work toward the same roadmap.
We also introduce scope creep. “Can we make this a little bigger? Can we solve it this more complex way? Can we polish this a little better? Can we replace at with this slightly larger thing?”
When I’m designing the layout and timing of my vegetable garden, I am project manager, designer, scrum master, and engineer all rolled into one. I’m also the executive funding the project, and as such, I’m not particularly fond of doing a ton of work that results in one $250 tomato.
I’ve learned a lot about sprint planning and scope creep from my vegetable garden.
I use a technique akin to square foot gardening for my vegetables. Based on the idea that you get more yield and fewer weeds if you plant the right things together in the right places, square foot gardening breaks down your planting plan to patterns. You can get 1 tomato plant or 2 cucumbers or 4 basil plants or 9 bush beans or 16 radishes in a square foot.
You can mix and match like-sized plants in a single square foot (so instead of 16 radishes maybe you have 8 radishes and 8 carrots) or if you keep an eye on your proportions, you can mix multiple sizes (2 basil and 1 cucumber).
Planning an agile sprint has a lot in common with planning a garden. If a square foot is a block of space, then a sprint is a block of time. It’s finite, and no matter what you do, it’s not going to change. Whether it’s a business process to be designed or a set of vegetables to be planted, when it’s full, it’s full. If you want to make more improvements or adjustments, they have to go in a different block. A good planner learns what will and won’t fit in those blocks and how to ensure that each block actually has roughly the same amount of stuff in it.
(For the purposes of this essay we’re going to assume that a sprint is 4 weeks long because I said so, don’t @ me.)
Everything grows
Sometimes you plant a cucumber and it sprouts, but something goes wrong, so it withers up and dies. It is extremely tempting to immediately fill that empty space with another cucumber seed. The thing is, the radishes have already sprouted, so the new seed isn’t going to get the sun you expected it to get when you put all the seeds in the ground together two weeks ago.
Or maybe you discovered a variety of tomato in those two weeks that you really want to try… that hole in your garden looks really tempting. But there’s no way that tomato and those radishes are going to all fit in that square foot and that means something is getting pushed out of the space.
Sometimes you’re in the middle of a sprint when someone discovers that due to an unforeseen technical glitch / back end problem / vendor is running late / etc. you need to pull a story out of the sprint. It’s easy to just reach into the backlog and grab the next thing in line without thinking about whether it will honestly fit in the time that remains. It’s so tempting that as a UX designer who quality tests her own stuff, I’m constantly reminding the developers that hey, they have time to get their part of that new story work done, but the quality test and UX tests and content validation won’t fit in there too.
You see, while the cucumber story was withering up and dying, all eight radish stories continued to grow and the team began pacing itself to fit the existing work. Nothing on week 2 of a 4 week sprint is the same size as you estimated it on day 1 of that sprint. And if you do decide to plant that tomato story on week 2, either your testers aren’t going to have time to test the tomato (if it even gets finished), or the radishes won’t get tested… they won’t all fit in the sprint together.
The reason we have agile backlogs is so that we remember we wanted to try that new variety of tomato and we want to give that cucumber variety a second chance, but not right now because it’s no longer the right time or place.
We can’t fix everything
Sometimes, instead of dying, the plant you plant on day 1 thrives… it grows beautifully and successfully. But whooeee is it ugly. You thought that corpse flower was gorgeous at the garden center but now that it’s starting to flower, the yard smells like rotting meat. It’s exactly the size you wanted it to be, it’s definitely been noticed, it’s doing everything you wanted it to do when you bought into the idea, but now what you want to do is plant marigolds all around it to hopefully cover up the smell. There’s not enough room in the corpse flower’s square foot, so you either have to overfill that square foot (putting all of the plants at risk) or push something out of the next square over so the marigolds can go in instead.
The corpse flower is huge and possibly pushing on the other square feet of garden. And it smells pretty damn rank. But it’s also providing pollinators with pollen, giving the neighbors something to talk about, blocking out weeds, and giving a threatened species a home. And yes, you’d rather plant prettier flowers that won’t make the neighbors wonder whether you’re running an abattoir in the back yard, but you can’t overrun your assigned space just because your threatened species is ugly, especially if you’re achieving your goals.
The right answer is to seriously think through and reprioritize the space around the corpse flower based on your new needs.
During sprint planning, your Agile team may have planned a product for two sprints. Less than a month in, you’re hitting all your goals. You’re also noticing every crack and mistake in your designs now that they’re in test. You realize you could make it a little more usable here and a little more marketable over here, and what about this no-I-swear-it’s-tiny accessibility fix? Suddenly the product that started as closer to “minimum viable” than “perfectly polished”, the product that you knew was never going to be a prize-winning rose, is outgrowing its launch date, not because it doesn’t work, but because it could be better and smell better.
The design can always be better. The garden can always be improved. The UX can always be more effective. The accessibility can always cover more use cases.
The right answer is to work with your team to reprioritize the second sprint based on your shared goals, and see if everyone agrees to adding marigolds and pulling beans out.
The more popular answer is to try to cram as many marigolds as you can into this sprint and next, because sleep and lunch are overrated.
Sometimes you have to stop yourself and say “I agreed to a corpse flower here and by golly we’ve got a successful one. I can ask the PM if she’s willing to give up some beans for some marigolds, but I can’t expect everything to fit in our plan. If the PM’s satisfied with the corpse flower and the customers can use it, I can wait until the PM’s ready to plant marigolds.”
And then you put the marigolds in the backlog and make notes in the design system about the overall usability risks of corpse flowers so the next designer has better information than you did.
Sometimes we all need a little space
Controlling scope creep, like controlling the garden, is also about knowing what works together. Some plants really hate each other. I mean really hate each other. Tomatoes don’t like to have a lot of nitrogen in the soil. You put in too much, you get fewer tomatoes and the ones that do form have ugly spots. Beans and peas, on the other hand, put nitrogen in the soil, a process called nitrogen-fixing.
Say you plant two feet of beans and then directly behind them you plant two feet of tomatoes. You know what you’re getting that year? It might be beans but it sure as hell won’t be tomatoes. You are going to miss your tomato goal significantly. You need to plant your beans and tomatoes far enough apart (in time or in space) that they’re not stepping on each other.
Companion planting is the practice of knowing which plants can go next to each others and succeed, and which plants will harm each other and fail, and planting accordingly.
Similarly, it is extremely difficult to switch from some kinds of project to others without a break during which everyone on the team can retool.
Let’s say this sprint you’re working on a database-heavy monolith project that’s UI driven. Let’s also say the next thing on your roadmap is an API-first designed set of microservices. Those are two vastly different sets of development skills. If the first project is building a complex web-based application for an internal enterprise organization, and the second project is a marketing site for a band, those are vastly different sets of UX design skills.
You can’t build certain kinds of projects back-to-back.
Well, I take that back, you can, but only if you get rid of the first team and then bring in a pre-built team that specializes in the second thing. The gardening equivalent would be those landscapers that come out to corporate parks and dig up all the daffodils as soon as they’re done flowering so they can plant fully-grown budding tulips. Instant successful plants! Massive cost! Giant amounts of waste!
If you want to build two very different projects , you need to plan space between them… maybe a sprint or two of bug fixes and education about the new initiative. It lets the team breathe, protects the first project from poisoning the second, and positions everyone better for success. Not every sprint has to be at top velocity; not every square foot of the garden needs to have a plant in it.
Planning is hard. Respect the sprint.
Whether it’s in the garden or the sprint planning ceremony, none of us can see the future. We can’t tell what will wither and die and what will grow twice its size. We can’t predict wild fluctuations in the weather or design for every possible outcome. And we can’t always take advantage of a gap or break, because of those very same fluctuations.
To ensure that our products launch and to build trust with our product and engineering cohorts, we must understand that a sprint is a sprint and a square foot is a square foot. We can’t afford to pressure our partners to cram new things in just because the first set came up stinky. We have to keep our own priorities in check in order for our partners to trust us.
This is not to say that we never push for change. On the contrary! We push for change all the time; wise changes are driven by the customers’ immediate needs and the potential failure of the project. If we find out the customer’s allergic to beans, or hates tomatoes, it’s our responsibility to immediately redirect our PM and Engineering partners toward the cantaloupe and the banana peppers.
If we manage our scope successfully during our sprints, one of the results is a well-stocked backlog ready to go for the next planning session, or the next rest sprint. We also have satisfied internal partners who trust us to provide what our customers and business need without undue pressure to overplant every sprint.
And if everything else went well, we have a hell of a harvest to show off to our customers.
