Scrum artifacts on remote setting

What is a Scrum artifact?

Scrum defines some artifacts to represent work done: The Product Backlog, the Sprint Backlog, and the Increments.

The Product Backlog is where Product Owners brainstorm and organize the product evolution. Product Backlog Items (PBIs) are sorted from the most important to the least important. This is a never-ending process, as Product Owners discover more opportunities ahead. Prioritization helps a company focus on delivering value vs. creating features with zero or little traction. This way, customer satisfaction and excitement go up; leading to further monetary growth.

The Sprint Backlog is more technical. It is a combination of a Sprint Goal and a set of Product Backlog Items selected for the sprint in place. The Sprint Goal defines a clear target to achieve within the timeframe of the sprint. A Product Backlog Item in a sprint may be broken down into tasks or subtasks. Each task describes the small steps required toward fulfilling the Sprint Goal. The outcome of the Sprint Backlog is a Product Increment.

In short, the Product Backlog serves as the “Why” and the “What” of the next thing to build. The Sprint Backlog describes the “How”.

Building good habits over maintaining a proper Backlog is key for the tribal nature of the Scrum team. It is the heart of communication. It is the campfire, where members of the tribe get together to share progress. So, keeping the Backlog information clear and in one single place, ensures that the whole team is on the same page at all times. Imagine the communication breakdown if, for example, information was scattered all over the place: in emails, chat threads, paper, or even verbal communication.

Managing a remote backlog

A team's Backlog within the office can be as simple as sticky notes on a whiteboard. A few vertical lines, with labels to describe the state (e.g., To-do, Doing, Done), and the team can add notes, move them around, or even discard what looks irrelevant or outdated. In general, a very fun and engaging way to stay on track and deliver a successful Sprint goal.

The purpose of the Backlog is to act as the one and only reference point for the entire team. The place where team members can see progress and refocus if needed. However, in a remote setting, the team needs to emulate the Backlog in a digital way, by making use of a digital board.

For a remote team, a digital online board is not the only way to get the job done. There are tons of online services and tools that do backlog management online, such as Jira, Trello, Asana, PivotalTracker, etc., to name a few.

The digital board system can notify the Scrum team of changes via emails or other notifications. Designs, documents, or links, make the digital backlog item rich enough for triaging and implementation by the team.

Keeping it all async

Having a detailed and up-to-date backlog is key for working within a remote team over separate time zones. The switch to async work may involve colleagues starting work much later or much earlier in the day. In this setting, ensuring a proper hand-off of your part of the job is critical. More often than ever, a remote colleague might depend on your deliverable to get on with their work.

Backlog management software supports comments for asking and answering questions and reporting progress. It's crucial for a remote team to know the state of each item in the backlog, flag items that need attention, or view items with impediments.

Keeping the information IN the backlog makes it easier for your team to ensure that no data is lost. Avoid the temptation to share progress in a private chat message, a video call, or something that will make the information leak from the whole team.

Best practices

Describe PBIs as user stories

It is strongly encouraged to use the user story format to describe Product Backlog Items. User stories are a great tool for Product Owners, fostering value-driven thinking. In a nutshell, the format of a user story is:

As a …(who)… I would like to …(what)…, so that …(why)…

The user story format holds important information that helps the team make decisions, design a feature, and take action. It is crucial to have all the elements of a user story in place. A brief overview of each user story element is:

• “As a…(who)” part defines the person that will benefit when this story is delivered. That person could be a persona or a specific role using your service.
• “I would like to…(what)” part describes the action that the person will do. Defining the action in a way that does not relate to your service, helps the team explore more solutions, e.g., instead of “I would like to click the submit button…” write “I would like to enter my data”.
• “So that … (why)” part defines the goal, the reason, behind the person’s action. This part of the user story is critical, as the team could identify alternative ways into achieving the same goal. For example, in order for a person to be always aware of changes in a software service, the solution could vary from mobile notifications, emails, or even an in-app banner.

If a user story is big enough, the Scrum team can break it down into smaller user stories, to ensure proper delivery within the sprint timeframe.

User stories are then broken down into technical tasks by the Development Team.

For example, let’s say that we have the following user story:

As a user, I would like to manage my notification settings so that I can get less distracted by pings throughout the day

This can further break down into a set of technical or non-technical tasks for the Sprint Backlog:

• Add notification setting fields in the database
• Create a notification settings page in the user interface
• Add server API endpoints, to update the notification settings
• Update user documentation with instructions
• Notify our users about the update

Keep the backlog lean

As the product matures, more feedback is gathered, and more customer requests are coming. This is where the backlog starts to grow. A big backlog is bad for the business. It may stall forward-thinking and further product discovery.

Usually, an item in the backlog creates the obligation for action and closure. However, this is not always the case. If you feel courageous enough, a radical practice is to remove all the old items and keep the backlog lean. After all, if an item consistently comes fort by your users, it probably sounds like a good priority for the next sprint.

In short, keep the skeletons away. Create room for forward-thinking and more product discovery.