The Misnomer of Agile Planning

Hello from the other side, the Elevator Up side. You might recognize my name from The Factory, where I was the community manager for nearly three years. Over the last two months, I’ve made the leap into Elevator Up as a Product Manager.

Throughout my transition, I was lucky to have had a lot of support from the staff and members of both The Factory and Elevator Up. Shifting into a sister company was beneficial for so many reasons. I was able to be pulled in here and there to observe client meetings, run through design thinking exercises, and understand the flow of product management meetings. Apart from the hands-on experience I’ve had, I’ve been setting aside time to learn independently, mostly by way of reading books and articles on agile project management.

While the agile process is relatively straightforward in most areas, one thing jumped out as feeling a little out of character. I had read that when PMs have a strong sense of what’s needed on their project, they’re able to easily plan out 18–24 months worth of work. Planning this far ahead had vehemently opposed every agile ideal I had read. I was asking myself how this ideal could coexist in the world of weekly sprints and small feedback loops. About a month in, I had an “a-ha!” moment that helped connect the dots between what I read to what we practice as a company.

The way we handle planning at Elevator Up explained my misinterpretation of “long term” agile planning. I soon realized that there is a stark difference between a plan and planning. In agile, we don’t plan the work and work the plan. Instead, we consider the idea of planning. This way, we’re able to remain flexible when plans change and quickly adjust according to new requirements and ideas. In short, I learned that agile planning is a pretty grey area, and it’s meant to be treated that way.

It wasn’t long until I realized long term agile planning comes into play in many stages of the project lifecycle. For example, there is a fidelity of long term agile planning that comes into play when estimating new projects. When we put proposals together, we have to have a relative idea of the work required in order to put together an estimate. In other words, a loose idea of what the product road map looks like is sufficient to this idea of planning out work in an agile manner over a longer span of time. This is the level of long term planning that is required at that time. But nevertheless it’s still a solid guess at a long term plan.

The idea of planning for the long term doesn’t come only with new projects. It’s a tool that can be implemented over the course of a shorter period of time, like a quarter year. As we work through projects, it’s easy to get caught up in the day to day and to find yourself slogging through tasks week after week. It’s important to think about and consider goals at a higher level. When we do this, we’re able to easily shift priorities if they change. As we decide on these higher level goals with our clients and our team, we gain alignment on what’s next. By thinking and planning like this, we’re able to lift our heads from the minutiae and think more intentionally about the high level goals want to complete, over a longer span of time.

The quarter plan makes it easy to keep high level goals in mind and the backlog clean. As an example, let’s say you meet with your client in on November 15, and they determine a goal that’s set to be completed the third week of January is no longer relevant. Instead, they decide they want to move a goal that was set to be completed in January to December. And, to top it off, the requirements have changed because they’ve abandoned a feature they no longer need. If you’re using the agile methodology, this change in plans doesn’t frustrate you or stress you out because you’re deciding on priorities together and intentionally building stories into the backlog to span a shorter amount of time, ideally 1–2 weeks in advance. By using this method, there’s no time or budget lost when priorities and requirements inevitably change. You’re cool as a cucumber.

Below is an example of a quarter plan I did as part of managing the work on our new website. By thinking through our current velocity and matching it to our goals, I was able to roughly plan where where we should be in a given month. As I ran through this exercise, I noticed the months that were further away definitely had fuzzier high level goals than nearer months, but that was okay. I was able to identify this and realize that’d require additional conversation to gain clarity on next steps.

After determining the high level goals, I used sticky notes to identify work that needed to be completed and scheduled it out on a weekly level. It’s good to have a gut feeling of work needed at specific times frames, and I only built out stories in Pivotal Tracker to account for two weeks of work at a time. This way, we were able to remain flexible on our future goals in case priorities were to fluctuate.

After I ran through this exercise on the whiteboard, I simply wrote it out using markdown and saved it in my project folder. It’s always best practice to include a digital copy and a photo of your work in your project notes folder in case someone accidentally erases your work. Plus, as I mentioned earlier, having these notes comes in handy for sprint planning.

Using the agile methodology is the best way to plan because it doesn’t allow for waste. By understanding high level goals of the project, the product manager is able to quickly adjust the plan based on changing priorities and client feedback. Planning your work and working your plan should only exist in sprint planning, but it is surely not the way to execute long term projects. Small feedback loops with your team and your client is the key when it comes to staying aligned and building the best possible solution.

~Amelie, Product Manager

~Amelie, product manager