Scrum Made Simple: How a Team Uses Artifacts in the Scrum Framework

Scrum Made Simple: How a Team Uses Artifacts in the Scrum Framework

The solution to some problems is so clear and straightforward that it’s like looking down a long, straight road to the horizon line. Take the problem of a scraped knee. All it needs is a good cleaning and a Band-Aid. Other problems are so twisted and complicated, however, that it’s not possible to even see around the first corner, let alone identify a solution.

While it may seem non-intuitive, most complex problems are best approached gradually, in stages. Otherwise, the end result can be disastrous. Take an online store with low sales. A software team could hunker down and build a “revised” site that’s just as ineffective, simply because it planned everything at the beginning and didn’t take any time to reflect and adjust.

Scrum is a methodology designed to navigate the complexity inherent in so many projects. Its specialized framework includes specific roles, ceremonies and artifacts. This framework provides teams with a roadmap that leads to creative solutions to tricky problems.

Artifacts are fundamental in this process. Want to understand how they function in the scrum framework? This post is going to list the three scrum artifacts, and explain how they work within the scrum methodology.

The Scrum Framework: Roles, Ceremonies & Artifacts

To anyone learning about scrum for the first time, all of the terminology may sound a bit funny. Words like artifacts, increment and ceremonies seem to suggest an investigation into an ancient culture rather than a description of a project management methodology. When the method is broken down, however, it reveals a system that propels teams through complexity and allows them to make creative products that otherwise wouldn’t be possible. It’s also a method that’s quite revolutionary, to boot.

The Purpose of Scrum

When faced with a gargantuan, complex project, a common temptation is to plot out every step, task and process carefully at the very beginning. Software developers in the 80s and 90s discovered that this rigid approach more often than not yielded a clunky product that the end user loathes. And so they set out to find a better way.

Two of these developers, Ken Schwaber and Jeff Sutherland, devised and refined the scrum method. Scrum, a word taken from a term used in rugby, takes an empirical and incremental approach to a problem. It suggests that the best products and solutions are discovered by tackling work in stages, then taking time to reflect and readjust before resuming work again. It’s an effective method to use whenever a problem has several unknown components, and where both the problem and the required skills are unclear. Scrum is one specific method within the umbrella of the agile approach to project management. It has its own unique structure, complete with specific roles, rituals and artifacts.

Roles

The three roles in scrum are the product owner, the scrum master and the development team. Each of these three roles perform specific tasks and work collaboratively to solve problems. The development team completes work in the sprint backlog, the product owner grooms the product backlog to identify critical work, and the scrum master supports the development team.

Ceremonies

The ceremonies in scrum include sprint planning, the daily scrum, sprint reviews and retrospectives. These four ceremonies provide the development team with sufficient structure to complete work meaningfully. The team selects work in small batches during a sprint planning session, completes it during a sprint, then takes the time to reflect on the work during sprint reviews and retrospectives before moving onto another sprint. This system allows sufficient time for the team to pivot and adjust mid-course in order to produce a quality end product.

Artifacts

And finally, the scrum artifacts include the product backlog, the sprint backlog and the increment. These artifacts prioritize work and allow teams to build a product piecemeal, with care and precision.

To be effective, each artifact must be transparent to certain groups of people. Without this transparency, critical information is concealed and a project is in danger of failing. Generally, the transparency is created by listing the backlogs onto whiteboards or electronic tools for remote teams. Increment is made transparent by sharing it amongst the team, stakeholders and clients.

With this overview of scrum, let’s now turn our attention to the artifacts specifically, and consider the role they play in the scrum framework.

Artifact #1: The Product Backlog

The first artifact in scrum is the product backlog. A backlog, broadly speaking, refers to an accumulation of unfinished work or unprocessed materials. The product backlog, then, means all of the tasks and requirements necessary to complete a project or yield a finished product. The product backlog includes user stories, features and enhancements.

The product backlog is made transparent to the entire team, client and all other stakeholders. This allows everyone to see the work going into the final product.

The development team plays an intimate role in measuring and assigning work to the backlog. The team develops its own “definition of done,” which is a list of all the criteria a task must fulfill before it can be removed from the product backlog. Additionally, the team assigns story points to the work in the backlog. This is a unit of measurement that gauges the complexity of a task. Scrum teams have found that story points yield better work estimates than a unit of time such as hours.

A product backlog changes continually with each upcoming sprint, as teams gather feedback and reflect on its progress. The product owner’s role is to groom the backlog, and select those work items that are most pressing and should be completed in the upcoming sprint.

A burndown or burnup chart assists with monitoring the backlog. These charts plot an “ideal” work plan at the beginning, then update it with actual work completed.

Artifact #2: The Sprint Backlog

The second scrum artifact is the sprint backlog. Just like the product backlog, the sprint backlog is also a record of unfinished work. However, this is the work allotted for one individual sprint.

At a sprint planning session, the development team gathers to select work from the product backlog for the upcoming sprint. The product owner has groomed the backlog to identify the most urgent work.

A team that has worked together for some time has a gauge of its velocity, or the amount of work it can complete in one sprint. Together, the team selects a number of tasks that correlate to its velocity. The work it settles on goes into the sprint backlog.

It’s helpful for the sprint backlog to be highly visible to the team members, perhaps with a white board. However, the sprint backlog need only be transparent to the development team. It’s not necessary for other stakeholders to see it.

In the daily scrum, the team monitors the backlog, and updates it as work is completed and backlog items are removed.

Artifact #3: Increment

The final scrum artifact is increment. It’s also sometimes referred to as the sprint goal–as increment, essentially, is the work completed at the end of a sprint.

Increment is a distinct, complete piece of work that contributes toward the finished product. While increment is considered “shippable product,” this characteristic isn’t always literal. In the project of building a website, for example, one piece of increment might be the login page.

To use a phrase common in agile lingo, increment isn’t simply “done,” it’s “done, done,” meaning that it fulfills all of the criteria in the team’s definition of done. Generally, this includes testing on the newly released software.

Increment is transparent to stakeholders and the team. It may or may not be submitted to the client for feedback. When it is submitted, the team listens carefully to the client, then integrates this feedback into upcoming work. It may adjust or tweak items in the product backlog to better suit the client’s needs.

An agile team aims to present increment to the client on a semi-frequent basis, from every couple of weeks to every few months. This allows a team to gauge its progress relative to the client’s goals, and then determine if it needs to pivot or course correct.