Trello is one of the most effective tools for driving your sprints. It's customizable for every Agile team and product owners and Scrum masters (SM) love it. However, Agile teams often struggle with:
My suggestion is to keep the product backlog on a user story map. Why? Trello boards are perfect for day-to-day work where the PM or SM specifies and distributes tasks for the current Sprint or release. In contrast, user Story Mapping provides a perfect overview of the whole product, making it easy to understand the context and goals. A user Story Map is the best place for strategic thinking (e.g., prioritizing ideas, planning Sprints, looking two steps ahead.)
There are ample educational materials on the web regarding user story mapping, so I will only give a short summary of the method. It's an Agile, user-centered planning method which starts with collecting user activities then exploring each step following a narrative flow. Activities and user steps (as sub-activities) are the backbone of the product backlogs. The body of the backlog is made up of all tasks, user stories, and ideas created through the narrative flow.
What does this look like? Each piece of information is written on cards and placed on the wall or in Story Mapping software. The planning team or the PO arrange the cards by moving high priority tasks upwards. Then, the body is categorized into working features.
In order to address the previously mentioned struggles Agile teams face, we have created a Story Mapping tool called StoriesOnBoard that offers real-time, two-way Trello integration. First, a new user can navigate a sample webshop filled with tasks in order to better understand how the software can work for them. Next, the new user can explore an empty Story Map which is connected to the Trello board.
I'm sure you've seen very long Trello lists with the longest (and most annoying) lists on the first and last sections of the board. This is because teams run into problems when trying to store cards outside of the current scope. Some teams opt to collect tasks of upcoming Sprints in separated lists, but this can cause problems for the development team, slowing them down; the development team performs better when they don’t have to deal with cards that are not relevant to the current Sprint. Teams often trim the board by archiving them, losing opportunities for retrospect.
We have a solution: by creating the user journey on a Story Map and importing tasks from Trello in one click, titles, descriptions, and statuses are synchronized.
Next, cards are arranged under user steps. (This efficiently detects holes in the product, but that's another story.) Then, the body of the backlog is sliced/categorized into Releases; if you don't have release strategy, then prioritize cards and group them into working features.
Now the Trello board can be wiped clean, archiving finished tasks and removing cards irrelevant to the current Sprint. (Don't worry! Removed cards remain on the Story Map! They can be imported later when the development team finishes the sprint.)
Trello boards manage all of the day-to-day development but often struggle to see the forest for the trees. A product owner must be able to see what the next quarter looks like in order to share further steps with contributors. Our method provides the perfect solution.
Ordering features into Releases create an easy-to-understand overview for stakeholders. This bird's eye view of the user Story Map exhibits:
This tool offers opportunities for predicting story points, hours, days, etc and development progression can be tracked via burndown charts or other reports.
Give the green light to new ideas, but don't leave them unscheduled. Our tool automatically separates new cards from the previously created backlog. Simply collect ideas via an input-list on the development board, then empty this list by sending cards onto the user Story Map. Prioritize new cards on a Story Map by either:
Hard to rank/categorize tasks? Create new releases based on a prioritization method such as Must have, Should have, Could have, Won't have (MoSCoW method).
Gergő
2 comments