And now for the tricky part. Once we sorted out the what and the hows through Product Discovery and Technical Estimates, it's time to put things into perspective. The goal of project planning is to create a reliable roadmap, from how features are prioritized and organized into tasks and sprints to actual milestones and project timeline.
Just like karma, everything starts with a backlog
Think of the backlog as the ultimate to-do list. It holds everything you should do throughout the project. Or, to put it otherwise, everything the app should be able to do, as documented in user stories and wireframes and agreed upon in the technical solution.
We like to think of the backlog as the single source of truth when it comes to the things the team will spend time on. And since the truth never gets outdated, neither should the backlog. We dedicate a big portion of project planning time not only to creating the backlog, but also to keeping it up to date. This process is called “backlog grooming” and usually takes place continuously in the background, as tasks are pulled out and organized into sprints and sprint backlogs. The goal is to always have at the top of the backlog at least one sprint`s worth of work which is clearly mapped out and organized into small, manageable chunks.
From product backlog to bite-sized tasks and sprints
A sprint is a set time frame, anywhere between one and four weeks — we decide the length of a sprint based on the complexity of the project. At the end of a sprint we should have a deliverable to test and improve upon in future sprints.
Before each sprint, the team meets to do sprint planning. This includes going through the huge, initial to-do list (also known as product backlog) and prioritizing it. There are a lot of things which may influence how features and consequently tasks are prioritized, but some of the most common are:
- Implementation difficulty
- Time and cost considerations
- Urgency of getting feedback
- Interdependency (B needs A in order to work; B is easier if we do A first etc.)
We use the MoSCoW method to prioritize features and, based on this, the tasks.
In addition to prioritizing features and tasks, sprint planning also means making sure that the tasks at the top of the backlog are always clearly defined and understood by everyone. This may mean breaking down large tasks into smaller sub-tasks or adding in new tasks as you discover gaps in the flow. During sprint planning, tasks are pulled out of the product backlog and the team commits to do them by the end of the sprint.
Sometimes, these meetings are also a great opportunity to improve your stand-up routine:
“Knock knock.”
Who’s there?
“Carrie.”
Carrie who?
“Carry it over to the next sprint.”
It’s funny ‘cause is true :(
Progress is in the cards. Literally.
Most project tracking software allows projects to be organized as sprint boards. We`ve worked with a few throughout the years, from Asana and Jira to, most recently ClickUp. A sprint board is a visual way to track progress using columns and cards.
At its most basic, a sprint board can be represented using four columns:
- To Do - basically the same thing as the sprint backlog
- In Progress - tasks the team is currently working on
- QA - tasks that involve testing. Test cards indicate how the task will be tested
- Done - completed tasks, removed from the board at the end of the sprint
As team members are assigned tasks from the sprint backlog and work on them, the cards move through the columns to indicate the progress made on each task. During daily stand-up meetings, everyone reports on what they are working on, what they will be working on and what stands in their way of completing a particular task. Team members update the board continuously throughout the sprint.
A card should answer one straightforward question and provide developers with as many resources as possible to answer it: “Do I know and have everything needed to complete this task?”. These resources usually include insights gathered during the previous two stages of the development lifecycle (Product Discovery and Technical Estimates & Solution) and can be added to the card to provide a full perspective:
User stories (provide context: who are we building this for? What is the end goal from a non-technical standpoint?). Sometimes, the backlog tasks themselves may be written as user experiences with the product: “As a < type of user >, I want < goal > so that ”.
Wireframes or the actual design of the screens that contain the feature (useful visual reminder for developers).
Bits and pieces of code, technical specifications & other resources.
A time estimate as to how much work the functionality requires to implement.
Wrapping up a sprint. And getting ready to do it all over again.
At the end of each sprint, two meetings are usually called. One with the development team and stakeholders (the sprint review) and one with the development team alone (the sprint retrospective).
The point of the sprint review is to allow the client to see what the development team has been working on and to provide useful feedback. The client gets a chance to see what's new since the previous sprint review, to interact with the app and see if any features have been miscommunicated or not communicated on.
While UAT tests (user acceptance tests) are not typically undertaken until all features are implemented, we use sprint reviews as a preliminary form of UAT testing. Or at least, the closest thing to a real-world test available. The team then uses the client's feedback to add new tasks, bug fixes and re-prioritize the backlog for the next sprint.
The second meeting, the sprint retrospective, is held internally with the development team. We use this meeting to see what adjustments need to be made to the process and if there is anything we need to incorporate in the next sprints. For this purpose, we created a super helpful list of questions:
- Project management (How well were the tasks assigned? How well were the dailies and scrum meetings planned and carried out?)
- Specs (Are all functionalities clearly defined?)
- Testing (How was testing conducted during each sprint?)
- Estimates & deadlines (How accurate was the initial estimation?)
This cycle is repeated until the MVP is ready to be deployed on live servers. Ideally, after the launch, small incremental improvements should be pushed regularly, after one or two sprints.
Gantt just got Agile
Gantt charts are a great way to visualize project timelines. We bring Gantt charts into our Agile project planning in order to track the status of important milestones and notice tasks which are extending deadlines.
Only an inexperienced project manager deals in absolutes. So rather than focusing on Waterfall versus Agile or Big Launch versus Continuous Development, we dream big and then take baby steps. We found this approach particularly useful for MVPs and start-ups. For example, founders usually need a high degree of predictability when meeting with investors. For them, launching a viable product within a clearly set timeframe is crucial, especially if their start-up has a short runway. But it's equally true that founders have a lot to benefit from the flexibility of sprint planning as they gather insights and their MVP matures. So why not start early with both?
Ready to get started?
If you’re a start-up looking for a technical partner to be there for the ride, look no further. We specialize in helping start-ups validate, launch and scale their MVP. Contact us now to get your project off the ground.
Top comments (0)