Our end-to-end cross functional task board
Visualising workflow is an essential technique that all teams looking to improve their efficiency and collaboration need to master. Task boards have long since served as a focal point for agile delivery teams, helping everyone understand what’s coming up and what’s in progress, where the bottlenecks and where the blockers are, and when certain tasks require special attention.
Everyone on the team, regardless of discipline, should be able to point at the thing they’re working on (physically or digitally) and have a good understanding of how to move it to ‘done’ and why they’re working on it.
We’ve worked in 100s of teams, and almost everyone has had a different way of visualising their work and structuring their task boards. From simple ‘To Do/In Progress/Done’ to 20+ columns tracking every subtle difference in state changes. There is no right or wrong way, and we firmly believe it should be down to the team to decide how they work, not imposed from above.
While engineers are usually pretty good at utilising their task boards, we’ve often seen a disconnect and disparity between how discovery and delivery work is managed and visualised. So, we thought we’d share how we typically structure our task boards to encourage good processes and provide end-to-end (discovery-to-live) visibility.
But before we get into our opinionated setup, there are a few caveats and things to consider:
Single or multiple boards?
We’re strong believers in working in cross-functional, stream-aligned product teams. These teams are responsible for both the continuous discovery and delivery of their product (or part of it). You can read more about our preferred team structure here.
With that in mind, our preference is to work from a single, end-to-end task board for a number of reasons:
- It reduces boundaries and hand-off between discovery and delivery work
- It provides end-to-end visibility
- It encourages engineers to get involved in discovery work and designers and researchers to ensure quality comes out the other end
However, we realise that this approach is somewhat idealistic and comes with its own challenges and limitations. You probably need to split into multiple task boards when:
- Your stand-ups are taking too long
- You have one discovery track/squad/team feeding multiple delivery tracks/squads/teams
Striking the balance between limiting your team’s cognitive load and ensuring everyone has a good understanding of where a task is and why they’re working on it, is again, something that the team should determine for themselves. We often start with an end-to-end board and follow this approach until it becomes too unwieldy, before splitting it up into separate discovery and delivery boards.
Scrum, Kanban …?
We’re also strong believers in ‘being agile’ vs ‘doing agile’. That is, we focus more on embodying agile values and principles than we do on slavishly following a particular methodology. You’ll therefore notice that our boards don’t follow the structures prescribed by these frameworks.
Now, let's dive into our task board setup:
The board
📋 Backlog
This is a catch-all for all ideas across the business. Whether they’re informed by the product strategy or roadmap, feature requests by customers, or insights from data or research. These could be expressed as hypotheses, insights, user needs, user stories, or whatever. Your priority here should be to continually refine and prioritise this backlog, and remove as much as possible. As this list can get quite long, you might only visualise the highest priority items in your task board to limit cognitive load, while maintaining a larger backlog elsewhere.
🔍 Ready for discovery
These are the items that you’ve committed to discovering – a prioritised list of things you need to learn more about before deciding whether, or how to build.
How many items you pull into this column depends on the complexity of the tasks and the capacity of the team.
Again, at this stage, these items could be expressed in a number of different ways, as it is the job of discovery to frame the problem in a way that helps you solve it. They could also encapsulate a range of different problems, from user to business, to technology. Discovery doesn’t just mean user research and prototypes.
It’s also important to note that not all ideas require discovery. We’ve written more about these scenarios here.
🕵️♂️ Discovery
This is a deliberately broad stroke due to the varying nature of activities involved in product discovery. Sometimes I’ve seen this broken down into a few columns: Research > Design > Validation, which can be useful if you have multiple specialist disciplines responsible for specific areas like product designers and user researchers.
Introducing WIP limits at this stage can be helpful to avoid spreading your discovery efforts too thinly. It is also where you would begin measuring the cycle time of a task.
👍 Review
We introduce a deliberate checkpoint to review the outcomes of our discovery and analyse our findings. While I’d advocate being as open, inclusive, and collaborative with your discovery efforts as possible, a separate review step gives everyone an additional chance to provide feedback and gain a better understanding of the upcoming delivery work.
📝 Elaboration
This is where validated opportunities are turned into detailed requirements in the form of user stories with clear acceptance criteria. We prefer to do the elaboration at this stage while the solution is still fresh in everyone’s mind to avoid context switching further down the line, as there is often a lag between discovery and delivery.
⏱️ Ready for delivery
This is a prioritised list of elaborated user stories you have committed to deliver. Stories shouldn’t be sitting here stockpiled for months on end. If items are sat in here for over a month or two you likely have an imbalance/bottleneck in your team. Stories go stale, user needs and requirements change, and waste is created as a result.
Here we often define an explicit ‘Definition of Ready’ policy to ensure the ticket is well-understood, testable, and has clear acceptance criteria.
👨💻 Development
This is where development begins. Like the Discovery column, this is often broken down more granularly into multiple columns such as ‘in-development’ and ‘ready for code review’. However, we have seen this encourage bad behaviours where engineers, once they’ve written their code, relinquish responsibility for getting the story released. Similarly, we try and avoid having an adjacent ‘Test’ column as we prefer our full-stack engineers to take on responsibility for testing their stories.
🧨 Ready for release
In an ideal world, a team practising true continuous delivery, shouldn’t need this column as each code change should be pushed to production, enabled through automated testing and deployment pipelines. However, few companies have this level of deployment maturity and instead release on a slightly less frequent cadence, such as at the end of their sprint.
✅ Done
The change has been released into the wild. Getting items to this column is the team’s primary aim, and they would usually celebrate and reflect on what has made it over at the end of a sprint, or periodically as they clear this column down.
In more mature teams there may be a ‘Measure’ column between ‘Ready for Release’ and ‘Done’, where items sit whilst the team proves or disproves a hypothesis by e.g. completing an A/B test.
Summary
So that’s our preferred task board set-up for encouraging continuous discovery and delivery.
Remember, task boards are tools to aid the team's work, and their effectiveness lies in the team's ownership and active engagement. Teams should therefore be given licence to experiment and refine their own task boards to optimise flow, drive accountability, and enable collaboration.
