Gathering requirements and getting an overall grasp of a new project can sometimes be challenging when there are a lot of moving parts. We are constantly dialing-in our process and coming up with better ways to organize a new build. I think we have a pretty good system, so I thought I'd share.
Make an inception deck with the client. The goal here is to ask all the hard questions about the project. Things like…
- Why are we building this?
- Will it make money (if that’s a requirement)?
- What’s the timeline?
- What are the higher risk points?
- Who is the competition?
- How many engineers will it take?
- What’s the elevator pitch?
- Most of the time all of our inception decks contain at least the points above.
Gathering stories with the client. Stories are, for the most part, features in the software. We write these stories down on colored sticky notes and start grouping them as best we can. At this point we keep the stories very general. Don’t get hung up on the details at this stage. A lot of times we stick these notes on a dry erase board so that we can easily move them around and draw lines to connect things up. The key to this meeting is to keep the client focused on the bigger buckets of the application.
Next we make a story map. We just pick a wall in the office and make a horizontal line with blue masking tape. This is our story spine. Above that line we write down the main feature groups of the application on large sticky notes . We order these left to right based on what we need to build first. Once our main feature groups are mapped out along the spine we make more detailed stories on smaller sticky notes under their main feature groups. We order these stories top to bottom. Top stories being the stories we need to finish first. Once this is complete we can make more lines vertically with masking tape to signify a milestone or a release. Don’t forget to write down the elevator pitch on a big card and stick that at the very top. It might sound a little silly, but you need to always be aware of WHY you’re doing what you’re doing. Keep that inception deck taped to the wall. Here is an example of the start of a story map for a project we are working on now.
Walk the client through the story map and identify the bare minimum of stories we can complete first before we do a release that people can use. Sometimes narrowing down the MVP stories can be hard for the client, but you have to stick to your Agile guns as best you can and make sure they understand the process and how it produces software that the target audience wants to use. This is also the best time to review scope / time and budget because the client can see all the moving parts. If the project is really big, don’t story map the whole thing out. You’ll just get overwhelmed and so will your client. When a project is this big (project over 6 months typically) a lot of things will change so focus on mapping out a major release at a time (1 month of work). Rule of thumb is if you’re feeling overwhelmed, you have to break it down into smaller parts.
Take those stories and put them in Tracker or something like tracker. The nice folks at Pivotal Labs have built a great tool for Agile story-based software development. You can read more here. We like to organize our stories with tags based on the top level features along our spine in our story map. This helps us stay focused. We also find it helpful on bigger projects to not load up more than a two months of stories into the backlog. Again the idea is to stay focused and not be overwhelmed. Don’t forget to set your iteration length properly and your velocity strategy. Typically we set our iteration length to one week and our velocity strategy to one week averages because we push code to our daily servers at least a few times a day.
Write awesome software! Keep your paper story map up-to-date with changes in requirements and importance. Don’t let your story map get out dated with the stories in Tracker. It may sound like extra work but being able to walk over to a wall and get an accurate picture of what you’re building is very important in all stages of the project.
The steps above really help us out. There are times we have to do more mind mapping to understand things better and sometimes we need more conversation with the client. We have even built story maps out to only tear them down because they were too complex. Keep it simple. Ultimately you have to do what works best for your team and your client.
Hope this helps you get your next project off the ground or gives you some ideas on how to get an existing project on track. We’d love to here what others are doing as well.