What Are Scrum Artifacts And How To Use Them
What are Scrum Artifacts?
What’s the best way to use them?
The Product Owner represents the voice of the customer. A Product Owner is responsible for turning the pains, needs and jobs of their customer into Stories in the Product Backlog, prioritising those Stories so the greatest value is delivered to the organisation and customer as soon as possible. All Stories are recorded in simple, non-technical language which is visible to all stakeholders. The Product Backlog is where all suggestions, ideas, requests, etc start out. The Stories are what “could” not will be turned into working software.
A Product Owner prioritises Stories based on the value the Stories provide to the organisation. This value is typically measured in ROI. These Stories are moved to the top of the Product Backlog because they have the greatest amount of detail. From there, the Development Team can choose which Stories to work on next, move them to the Sprint Backlog and turn the Stories into “potentially releasable software.”
As part of this process, the Development Team adds Estimates (see below) to each Story before working on them. Estimations are used by the Development Team to determine how many Stories it can complete in a single Sprint given its production capacity. The first Sprint is started as soon as there is enough information in the Product Backlog. As the Product Owner gathers information from the organisation, they add it to the Product Backlog. Over time, they refine and prioritise each Story in the Product Backlog ready of the Development Team. While there may be several Scrum Teams in an organisation, there is only ever one Product Backlog.
Product Backlog Items
Product decomposition is a technique used to break down large user Stories into smaller Stories. It helps an Agile team plan and manage improvements to a product. It also helps Agile teams better visualize where the benefits and features exist within the product. Typically, the product decomposition can be represented as a workflow of internal business processes and external customer journeys. It should focus on how the user’s experience and how an organisation is meeting the customers pains and needs while delivering value. Alternative techniques include process models, data flow diagrams, customer journey maps and user story maps. Below is an example of how to break down the job of ordering a pizza online.
Epics are Stories that have been added to the backlog but have not been decomposed into smaller Stories. Epics will have a broad context or high level idea and little to no detail. These will be broken down into Themes. The size of a Story in the Product Backlog is broken down from Epics, being the biggest, to Themes, and then Stories. Once a Story has been moved from the Product Backlog to the Scrum Backlog it is broken down by the Development Team into Tasks.
Stories should be kept independent of each other. Themes, however, are typically a group of Stories that relate to each other. The relationship could be with regards to a Sprint goal, a feature, or something similar.
Epics are broken down into smaller and smaller units until they become Stories. Stories are the building blocks of any Agile project. They are a self contained unit of work agreed upon by the Development Team and the stakeholders. The information in a Story MUST be non-technical and independent of other Stories. Stories have a specific format to help teams better understand what they’re building and who for.
As [customer segment], I want to [task to be completed] so that I can [why task needs to be completed]
As a customer of ABC Pizza, I want to have my pizza delivered within 30 minutes so I can enjoy it while it’s still warm.
To determine if a Story is set out correctly, a Product Owner should use the I.N.V.E.S.T acronym.
Independent : Should be able to be implemented on its own without the hindrance of any other Stories
Negotiable: The Story should have enough information so the Agile team knows what to build but also enough flexibility so they can determine how to build it
Valuable: Each Story needs to be valuable from a customer’s point of view
Estimable: The Agile team might not know the exact amount of time or resources it will need to complete the Story
Small: The Story needs to be small enough that it can be completed in one Sprint
Testable: It must be testable from an acceptance testing criteria and customer point of view
Ordering The Product Backlog
A Product Backlog is a prioritised list of what an Agile team will deliver. A healthy backlog assures the right Stories are being worked on at the right time by the right people. A Product Owner is responsible for the process of gathering stakeholder requirements, adding them to the Product Backlog and ordering the Stories with the most valuable at the top of the Product Backlog. When organising the Product Backlog a good rule of thumb to use is to organise Product Backlog items into four sections. The first is the “top 10” items that will be worked on next. Second, is the “next release” items. Third, is the “subsequent release.” Finally, “the rest” of the Product Backlog items.
The closer to the top of the Product Backlog, the more detail a Story should have. This detail is added just in time so time and effort is minimised when managing the Product Backlog and the focus is spent on delivering features and benefits that provide value. While the Product Owner adds all the requirements to the Product Backlog, some may never be built as they do not provide value to the organisation or the customer. What is critical to understand when grooming the Product Backlog, is that information is ordered in a way that is valuable to the organisation and the customer. It is not organised based on who will complete the work, the technical specifications or anything else. There are several different ways for a Product Owner to order the Product Backlog based on the definition of value.
Return On Investment (ROI): Measures the gain or loss generated on an investment relative to the amount of money invested. ROI is usually expressed as a percentage and is typically used for personal financial decisions, to compare an organisation’s profitability or to compare the efficiency of different investments.
Net Present Value (NPV): NPV is the difference between the present value of cash inflows and the present value of cash outflows over a period of time. NPV is used in capital budgeting to analyse the profitability of a projected investment or project. Put another way, it is a measurement of profit calculated by subtracting the present values (PV) of cash outflows (including initial cost) from the present values of cash inflows over a period of time. Incoming and outgoing cash flows can also be described as benefit and cost cash flows, respectively.
Payback Period: This is the total time it takes an organisation to recoup the money it spent on developing the product or service.
Internal Rate of Return (IRR): The internal rate of return (IRR) is a method of calculating rate of return. The term internal refers to the fact that its calculation does not involve external factors, such as inflation or the cost of capital.
Total Cost of Ownership (TCO): TCO is the total cost of the deployment and the operating costs of the product or service.
Traditionally, estimating how long it will take a team to do something is measured in person-hours or person-days. If it is stated that something will be completed in e.g. 10 days and it takes longer, there is an assumption that something went wrong, there was a problem or a negative outlook on the team. Scrum avoids these types of problems by using Story Points to estimate work instead of time. The first step in the process is to identify a simple Story that has been completed several times before. Everyone should know how long this specific Story should take to complete. This Story is then assigned 1 Story Point and is used as a reference for all other Stories to be completed.
As mentioned above, it is the responsibility of the Development Team to estimate the work to be completed within each Sprint. One way to achieve this, in an unbiased way, it to use a technique called Planning Poker. Each member of the Development Team is given a set of Planning Poker cards. The cards are labelled like so:
These are the steps in Planning Poker:
- Estimating begins by having the Product Owner explain the Story to the Development Team and everyone making sure the Story is clearly defined and understood
- Each member of the Development Team picks a card they think most accurately represents the estimate of work needed to complete the Story. It’s important to note, at this point, no one has shown anyone else their chosen card. This is to eliminate any bias
- Everyone in the Development Team turns over the card they have chosen. If all the cards are roughly the same, the average is calculated and that is used as the estimation for that particular Story
- If there is a large gap between any two or more cards, it is clear the information in the Story has been interpreted differently by different members within the Development Team. As such, the Story is discussed again and the Planning Poker process repeated until such time as the numbers presented are within a similar range.
To use Triangulation for estimating Stories, use a table with the same numbers as in Planning Poker. Here, each Story is added to the column the team thinks most accurately represents the estimation for that Story.
Ideal days / Ideal hours
This estimation method allows the Development Team to estimate the time required to complete a Story in an ideal situation. It might be that a Development Team has a known capacity during each Sprint. This is calculated by the number of people in the Development Team multiplied by the hours of work during a week. Even though the Development Team might have a maximum amount of capacity, due to many factors taking time away from the team during the week e.g. meetings, holidays, distractions, etc, they will have a smaller amount of “ideal time” to complete Stories.
Scrum is designed to deliver usable pieces of software throughout the project and get feedback from the customer as early as possible. This removed the need to build the whole solution up front and deliver it in a “big bang” at the end of the project. An example of Release Planning might be, a Scrum Team have completed three Sprints and delivered “potentially releasable” Increments of software at the end of each Sprint. However, the software is only “potentially releasable.” Scrum doesn’t dictate that it must be released. It is often much more efficient to release software in a more organised way and according to a Release Plan as there are additional consideration that need to be taken into account i.e. training, support, marketing, reporting, etc.
The Release Plan is done by the Product Owner with input from stakeholders. While no formal Artifact for a Release Plan exists in Scrum, a Product Owner can choose a number of different ways to approach it. A Product Owner could take an ad-hoc approach and deliver the software whenever it becomes available. They could release whatever is available at predefined times or release software based of the set of features that have been completed. The most important thing to note is that the software must be 100% complete.
I hope you found this helpful. If you have any questions, feel free to reach out or comment below.