Agile development is made to thrive in change. To ensure that teams are working towards your product milestones through uncertainty, you need to use a scrum task board to track all the work done by the team. Whether you use a SaaS tool like Jira or Trello, or even a physical one with post-it notes, there are some components that are required to properly track your scrum development. We will go over how to use a task board, break down tasks for scrum, and prioritizing the tasks.
How to Create a Task Board
Task boards are primarily a project management tool to keep track who is doing what in an open transparent way. In its simplest form, you have four columns: To do, In progress, In review, and Done. A person is assigned the task of updating the card on the task board.
There may be more columns (such as In system testing, etc.) that you might add to have more granularity on task progression. You don’t want the task board to be a burden for the team to work with. Instead, it should aid you with making progress towards the sprint goal. You can also implement swimlanes, extra row categorizing subtasks within a story, for more granular tracking.
Movement on the task board can be used to create scrum artifacts, such as sprint burndown charts. This means that each member in an agile team needs to actively update the task board when tasks progress, both to communicate to the team as well as creating these scrum charts. You can also have a velocity chart that tracks across different sprints.
Remember, software development is unpredictable, and sometimes tasks have unexpected complexity in them. For example, a task for adding an extra feature in an app might have complication with user interface (UI) resolution on different devices. Working on few large stories can significantly affect the sprint if even a single item is impacted. Therefore, to remove uncertainty, we need small chunks of tasks to incrementally track progress.
Breaking Down User Stories
Task breakdown is one of the key steps to do when doing backlog grooming. This also means that proper story point estimation needs to exist for you to use taskboards effectively. Story points represent the size and how complex the task is, and differ from team to team. The value of story points is to compare different stories and how much more effort relatively needs to be taken to complete the story.
The team’s experience, after a couple of sprints, will improve its accuracy of story point estimation. The team then can tell when stories are too big to be done in a sprint, and thus need to be broken down. Just how small the stories need to be broken down into depends on the duration of the sprint. What is more important is how you break down these tasks.
When you break up large user stories, make sure you do a ‘vertical breakdown’ and not a ‘horizontal breakdown’.
Horizontal breakdown is a common approach that teams use when breaking down tasks by the different technical and functional layers of a user story. An example is breaking a task into the UI, front-end client, and then system testing. However, this will not work well in scrum since the deliverables are not working demonstrably on their own and encourage silo thinking.
Vertical breakdown is user stories broken into smaller user stories that are working demonstrably for an end user. This would mean the tasks taken for these small user stories are across functional layers for the feature and thus have a chance of providing value to the customer at the end of the sprint.
Let’s take an example of a large user story:
- “As a user, I want to buy goods online so that I can get them delivered to my house.”
Some strategies we can use to break down the task vertically include:
- User workflow or test scenarios
- Shorter user story: “As a user, I want to log in, so that I don’t need to re-enter my information for every purchase.”
- User roles
- Shorter user story: “As an advocate user, I want to buy repeated goods online so that I can get them delivered to my house weekly.”
- Shorter user story: “As a user, I want to log in on Android, so that I don’t need to re-enter my information for every purchase.”
Prioritizing the Product Backlog for Milestones
Now that you know how to break down tasks properly, you need to arrange the product backlog. A product backlog is a queue where you store upcoming user stories and epics (larger stories) that your team will work on in the coming sprints that will fill the features for milestones mentioned in your product roadmap. These stories could already be broken down and estimated from an earlier storytime, or are still larger stories and epics that have yet to be broken down.
It is the product owner’s responsibility to make sure that the right things are being worked on at the right time, i.e. the correct prioritization of the task for timely completion of these milestones. You need to focus on the must-haves for your targeted user role in the minimum viable product (MVP), followed by the shoulds and coulds. To help with decision making, refer to the Eisenhower decision matrix to guide your focus on important and urgent user stories.
These priorities could change over time, so whenever there are changes to your requirements, revisit the backlog order and see if they still make sense.
To track progress on your product milestones, you can create release burndown charts from previous sprint information. To learn more, have a look at our burndown chart article.
Now that you know the best practices on how to use a task board and the importance of breaking down stories and prioritizing them, you can be confident that your agile progress will stride to hit those product milestones on your roadmap.