Once you’ve completed the preparation steps and assembled your team, it’s time to start building your app. However, where do you start? In what order should you build everything that you’ve outlined in the spec document? To figure that out you need to create a roadmap containing all user stories you want to develop prioritized by their importance. With a roadmap, you can always see how quickly you move throughout the set of user stories, what is your next step and what lies ahead. Don’t treat the roadmap as something fixed that you need to follow — you need to continually refine it and adjust priorities and estimates as you learn more about your product.
The roadmap in agile development
In the agile development process, a roadmap acts as a compass for the team. It shows what user stories should be completed and in what order, based on their value. However, why do you need something like that, why not create a project plan as used in traditional waterfall project and implement it step by step?
The main difference between agile roadmap and traditional project plan is flexibility. Software development projects are highly unpredictable — you don’t know how much time it will take to implement specific user story until your developers spent some time working on it, and even after that an estimation can still be off.
Another source of unpredictability is users. The goal of the agile development process is to get feedback early on. If you postpone getting user feedback until everything you’ve scoped is ready, you will set yourself up for failure. A user test might reveal severe flaws in logic overlooked during scoping phase or critical bugs that take quite some time to fix, or major UX problem that prevents users from performing their tasks. These problems are inevitable, but the earlier you will know them the earlier you will address them
Because of high uncertainty, you need to continually test the app with users, starting as early as you can. Of course, you can’t show something underdeveloped to the broad public, so you need to create a launch team. A launch team is a team of early adopters, preferably the ones you were interviewing at the early stages. You don’t need a lot of them — 3-5 people will be more than enough to get feedback. You can have bi-weekly calls with them showing your progress and listening to what they think.
The roadmap has to be refined at least every two weeks based on user feedback and technical knowledge you’ve gained since last roadmap refinement. This period is called a ‘sprint’ in agile methodology. A project manager (or you, wearing a PM hat) assigns goals for a sprint, aiming to implement user stories to the point when they are ready to be used by users and provide value. At the end of the sprint a project manager and a product manager do a retrospective to understand what has been learned during the sprint.
Maybe you’ve realized that search-related user story that you planned to implement in two weeks takes two months. You can then decide to split that user story so that the user can search using only one field instead of five and complete it during next week, instead of spending two months.
Same happens with user feedback. You might have an archive-related feature on the roadmap that consists of several user stories. After completing the first one, you show it to users and learn that it’s not something they want or need even though they told you the opposite before. You can then deprioritize other archive-related user stories and build something important instead — for example, an audit trail, because that’s what users are asking for.
Managing the product vs. managing the project
Product management is often confused with project management because they both are related to managing the development process. They are different, though sometimes both roles are performed by the same person.
Product management is more about defining what should be built and when. It’s a strategic view of the whole set of requirements. A product manager connects the development team with users, steering the development process in the direction that brings the most value to them. He makes sure that the app that is built will get used by the users and that only the most important features are implemented.
On the contrary, a project manager is someone who is responsible for tactics. She defines the day-to-day development process and connects team members with each other so that they have all questions answered and nothing stands in their way. A project manager is responsible for the completion of user stories and features added to the roadmap in the order defined by the product manager and on time.
Velocity and burndown rate
As a project manager, you need to track two key metrics — your team’s velocity and burndown rate. Tracking them will allow you to make the right decisions about the roadmap when choosing the order of user stories.
Velocity
Velocity is a relative metric of how much work is being done during the sprint. It’s a very abstract metric, but it’s still useful for long-term planning. The idea is that your developers estimate user stories in points. Each user story is assigned 1-5 score by each developer, and then an average is calculated. It’s important to go through all user stories at the beginning of the project and rate them using this scoring system. It will allow you as a manager to see the relative effort required for each user story.
Based on the number of points completed each week you will be able to forecast how much time it will take to complete the whole project or a specific release that consists of multiple user stories. Does this system work? Sometimes it does, but sometimes it’s tough for developers to estimate how hard it will be to implement something that depends on another unknown functionality. Velocity metrics become essential in the middle of the project when the cone of uncertainty becomes more narrow. Once you move closer to the deadline or the budget cap you have for the project, you will need to make educated choices about your next steps and velocity can help you.
Burndown rate
A burndown rate is a simple chart showing you the number of resources you have available (either time or money) to the number of user stories completed. It gives you a clear picture of how you move throughout the project and allows you to see problems early on.
Say, you have a $100K budget and 100 user stories completed during ten months. If you look at the burndown rate, you might see that instead of completing 30 stories you’ve implemented only 10 of them. You can then refine the roadmap and plan to implement only the third of the features you wanted to have initially.
