Agile boards: A DIY Guide for newbies

Have you heard about SCRUM?

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.

The board: a key tool for your team

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?”

First things first

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.

FAQ QAF: Questions to ask frequently

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.

Who’s the squad?

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.

Which are the steps of our delivery process?

To design the structure of the tickets, it’s necessary to know what it takes for any feature to be completed, for example:

• Define and prioritize the scope
• Create the backlog
• Set up product architecture and database
• Design user interface
• Validate with the business
• Write down requirements
• Development
  • Front-end
  • Back-end
  • Integration
• BA sign-off
• Quality control
• User Acceptance testing

These phases can be managed with stories, sub-tasks, statuses, or a combination of any.

What does it take to have a User Story ready for Development?

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:

• Specifications are complete, clear, and approved by the business.
• Database is ready
• Project architecture is ready
• User Interface is designed
• Blockers or strong dependencies with other teams are resolved or near to completion

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.

Which is our development process?

The sub-tasks and item statuses should be planned based on the steps of the development process. Some basic questions to consider are:

• How many environments does the team handle and which is the purpose of each?
• Are back-end and front-end developments handled separately?
• Do we include units tests for each user story?
• Are code reviews required?
• When and where is it tested?

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:

• The level of granularity or details that is required by managers or any other stakeholder
  • Stakeholders may require different amounts of information depending on things such as the stage of the project, or the number of projects they handle. The board should be granular enough to allow all kinds of reports to be extracted from it.
• The completion of one task conditions other team members work:
  • When a team member or a team process depends on the completion of a specific task, it might be worth tracking it to avoid confusion. E.g: Deployment to a test environment allows testing to begin.

How do we handle story bugs?

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:

• To which items should the bugs be related and at which level of the tree structure
• Bug severities 
  • Which are blockers for the user story to be completed
• In which sprint will the bugs be handled (current, next one?). Include bug severity in the definition.
• When is the testing phase finished? 
  • Is it possible to complete the testing with bugs opened?

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. 

When is a story “done”?

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.

How is our progress monitored?

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.

Last but not least

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.