Agile boards: A DIY Guide for newbies
By: Marilyn Rodriguez
Tags: Agile Methodology, Scrum, Project Management, Software Engineering

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.

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:

· 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.

Remember to configure the ticket fields to the team’s necessities. For instance, testing could be indicated using a US status or a sub-task like it is in the schema above.

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 work, 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.

2. 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 permits the testing to begin.

Workflow example using statuses and sub-tasks.

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 all 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 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 reflection of your progress and opportunities to learn, grow and shine.