There are as many ways to do Agile as there are businesses doing Agile. As consultants, we’ve walked the path from Waterfall to Agile with many clients, and there are some common challenges and misconceptions about how work should be planned, organized, and documented in an Agile environment.
“Agile means we don’t waste time on a lot of project planning. We just get right to work.”
“Agile means we don’t need to create documentation. We just add user stories to a backlog, prioritize them, and start developing from that.”
“Agile means we don’t need project management.”
These statements misunderstand the Agile philosophy, which doesn’t advocate for throwing out planning, documentation, or management. It just states that those activities should support instead of drive the process. For most businesses, a balance is required. Just enough planning, documentation, and management helps Agile teams be more effective and mitigates risk.
We Should Have Started Yesterday!
Let’s look at an example of a client project I worked on a few years ago.
I was helping them with the requirements for an application that they planned to build in-house. They had decided to give Scrum a try, so I was also helping them with that transition. Originally, they had planned to purchase off-the-shelf software, but after a vendor evaluation, they realized that none of the available solutions met their needs sufficiently. Moving from “vendor selection” requirements to “development” requirements meant filling a big gap in detail.
In our first planning meeting, I had no trouble figuring out what the analysts needed to do, but the developers just looked at us and asked what should they work on? This put us in a bind; we needed to do some work to create the product backlog before the developers could really get started. Of course, there were a few things from an architectural perspective that development could work on. However, the developers really needed requirements so they could start building features. We worked as fast as we could, understanding the problems the project was designed to solve, developing a list of features to solve those problems, and getting those features prioritized. From the prioritized list, we were able to write enough user stories for the developers to start with. It took us a few weeks, but then the dev team had confidence that their sprint backlog consisted of valid, priority user stories.
Go Fast but Plan First
How can organizations switching to more Agile processes or starting a new project in an existing Agile environment mitigate this gap that can leave analysts scrambling and devs twiddling their thumbs?
One approach a lot of teams take is holding design sessions where the entire team works together to brainstorm backlog items. The problem with this can be that without structure, the resulting user stories can be all over the place, requiring a lot of further analysis and prioritization before they can really be planned into sprints. I am not advocating that we take a waterfall approach to documenting all of the requirements before development can start, but some high-level planning can help get analysts and developers aligned and provide a framework for prioritizing and planning the subsequent project work.
First Things First - Business Objectives
I recommend starting by building a Business Objectives Model (BOM). This will help the entire team understand what problems the project is trying to solve and how you will know when the problem has been solved. Use this model throughout your project to ensure that you are working towards those objectives. If features/requirements come up that are not covered by the BOM, explore why. Is it scope creep? Or do they help solve a problem that was overlooked when the model was created?
Next - Brainstorm a Feature Tree
Next create a Feature Tree. This can be done fairly quickly by bringing your subject matter experts together to brainstorm the features that are needed. I like to use sticky notes (virtual whiteboards have these too) and then put into a more structured form later. Once you have the features written, you can prioritize them. Use your Business Objectives Model to help you prioritize. This list of prioritized features becomes the start of your Product Backlog.
With a prioritized list of features in place, you can focus on elaborating user stories for the highest priority features. Usually, some features will be better understood than others and easier to quickly elaborate, giving your team some “breathing space” to tackle the more complex analysis.
Document Processes to Elaborate Features
I find that current and future state process flows are the logical next step in the analysis process. Process flows for top-priority features can add significant clarity to the backlog and expose gaps in our understanding. Ideally, the detailed steps of a feature process flow become one or more user stories in our backlog. Most teams, as they go through this elaboration process, will add the user stories under a feature “bucket” in the backlog as a handy way to organize the work items. The feature is considered done when all of the user stories under it are complete. Of course, once work begins, work items can move around, be prioritized or de-prioritized, etc. as the team continues to learn more about the product and the project.
