To start speaking about team boards, first we need to get acquainted with agile frameworks like SCRUM. The purpose of these frameworks is to help teams work together, learn from experiences, self-organize tasks and at the same time review and improve internal processes. In the IT field, we use this framework for developing, delivering, and maintaining software solutions. This means that to organize, plan, prioritize and assign work or tasks the teams need tools that help them to achieve SCRUM goals.
Without tools to organize the pile of work that needs to be done to deliver a software project, you can only plan so much.
The board is the tool that the team can rely on to plan their work based on the timeline, the backlog, the number of team members, and their expertise area. In turn, the backlog can be organized based on business value, dependencies, priorities, complexity and more. Then, each step in the delivery process should be reflected in the backlog’s items workflow.
The simplicity and intuitiveness of this workflow should be so that it enables the team players to know what’s expected out of them and so that it facilitates the resources to complete it. Needless to say, the team progress should be crystal clear on the dashboards.
The development process should fit the project, technologies, and team members, and so should the work-items journey. We said that agile teams are in constant evolution so, above all, the workflow should be flexible. It must feel alive.
Then the million-dollar question is “How can we build a perfect workflow for our team and project?”
You can rely on many different resources to build your team board, so make it as personalized to your needs as possible. You can set up the tickets’ required and optional fields and the different possible statuses for each kind of ticket. IMHO the basics you’ll need are: Release information, priority, ability to add comments, dependencies, labels, story points, estimated and actual hours.
The board and tickets workflow should be designed according to their needs by all team members, cooperatively. As a matter of fact, both should also be reviewed every now and then to validate that it still reflects the actual development process.
Well… you’ll need to start with something so, by asking yourselves the right questions, you’ll hit the nail.
By knowing the people that will be part of the project we should be able to determine the different phases that the development would need, creating both time and space for everybody to do and track their work. For instance, while creating sub-tasks for a User Story, we should consider if the team has back-end and front-end engineers. Also, on native mobile apps, iOS and Android development and testing can be tracked separately with User Stories or sub-tasks.
When speaking about Quality Control, there are different aspects of the development that can be tested, and different moments and experts to do it, so this information is also vital while defining item statuses, or sub-tasks.
The important thing is to have a convention that works well for everybody involved.
To design the structure of the tickets, it’s necessary to know what it takes for any feature to be completed, for example:
These phases can be managed with stories, sub-tasks, statuses, or a combination of any.
A usual tacit assumption is that if a user story was included in the sprint backlog, it is ready to be worked on.
User-story readiness has to do with previously completed definitions to ensure that the development process runs smoothly during the sprint. For instance:
On some occasions the pre-planning ceremony is useful to review all these aspects of the stories inside the sprint backlog, and for the team to raise concerns about any of them. Otherwise, including stories in the sprint backlog is the green light the developers should be waiting for. Nevertheless, it is a good practice to use dependencies across stories included in the same sprint, and ticket priority so that higher priority items are finished first, avoiding carry-overs of tickets of great value for the business or tickets that could cause a bottleneck for other developments.
The sub-tasks and item statuses should be planned based on the steps of the development process. Some basic questions to consider are:
The answers to these questions determine not only the number but also which sub-tasks should be created by story as default and which need to be completed before another can be started.
By no means this implies that all the activities involved in the development process should have their own sub-task. It could be agreed with the team members involved, that one or several of these activities should be completed for the task to be marked as done.
My suggestion is that the task should be tracked separately depending on these 2 factors:
Bugs happen. Therefore it is important to include them in our plans.
First of all, it should be determined at which level is the testing will be performed and then, the team should set up clear definitions regarding:
The discussion and agreement on these topics would help not only define our ticket structure but also to understand the exact status of any item on the board. It would also provide information on which fields are mandatory for this item type and which are optional. Conditions can be changed after some time, with feedback on what’s working and what’s not from the team.
The sprint goal is to complete the work the team forecasted during the planning meeting. Therefore the Definition of done is vital for the development team, because it will provide everybody a shared understanding of what work needs to be completed for an item to be released or even presented at the sprint review.
With this information the team can create specific statuses and play with sub-tasks that will reflect the processes needed to achieve that goal. Finally, they’ll determine the person or role responsible for closing each task, and the one giving the final sign off that will mean: “This ticket meets the expectations to be presented to the client”.
Depending on the development process, the sign-off could be given by a Business Analyst, a Quality Control Engineer, or the Product Owner itself.
Whether it is to send a report to upper managers about the status of the project at high level, or to monitor development hours completed and pending, the project managers should count on the information that they can extract from the team’s board.
All the data contained in the work items, can be transformed into valuable information if used wisely.
So, plan ahead on what it will be required by upper management, cross-teams, yourself, and by the team to monitor their progress. With this in mind, make sure to include all the fields and granularity that you will need later, to turn raw data into a reflexion of your progress and opportunities to learn, grow and shine.
Tickets definition and workflow will give your team and managers plenty of information about progress, bottlenecks, things that are working great and others that can be improved, so use it!
I don’t want to paint a rosy picture, but I mean it when I say that your team will benefit a lot from designing its own board and ticket workflow. It will create transparency and the perfect environment for processes to run smoothly.
A word of advice: use retrospectives to touch base with regards to the team’s feelings about the board, and make it an excuse to discuss the processes themselves and how they’re impacting on the team’s performance, for better or worse.