Scrum Artifacts Tutorial

5.1 Scrum Artifacts

Welcome to lesson-5 of Simplilearn’s Agile-Scrum training program. In this lesson, we shall talk about the various artifacts associated with Scrum. In this context, we would understand how requirements are managed in Scrum.
We will first look into the agenda of this lesson, in the next slide.

5.2 Agenda

Let us now look at the detailed agenda for this lesson. We start off by looking at the “backlog”. The backlog consists of user stories and epics, and we discuss those in detail. The starting point of any successful project is requirement definition. We shall try to understand how to write good requirements.
Finally, we look at how to split up stories. Splitting stories is important because a story should be small and deliverable independently as a unit through an incremental, iterative approach.
Now, we will proceed to the next slide to start with the Product backlog.

5.3 Product backlog

Backlog is a somewhat unfortunate choice of term. Backlog is to be understood here as everything that is “yet to be done”, not necessarily that the team has fallen behind!
The product backlog is the collection of everything (work) that the team could do to add value to the customer. Every such work item is expressed as a user story or an epic. All the items in the backlog need to be ranked and prioritized by the product owner.
Ideally, the product owner needs to have a fair amount of detail in the requirements or stories that will be taken up for work within the next 2 or 3 Sprints. The rest of the stories can be kept at a fairly high level. The backlog is obviously a live document or list that the product owner continuously updates.
Next, we will continue with the product backlog.

5.4 Product backlog

Let us look at a small list of items that can be part of a product backlog.
Each item in the backlog is essentially a short description of a “requirement” or “change” that is needed to the system to meet a particular customer need or to add value to the customer. The description of the item is provided by the product owner in consultation with the stakeholder who voiced the requirement. The size is expressed in some units, and is provided by the team. We shall dig deeper into the sizing when we talk about Estimation in Scrum.
As you can see from this list, items in the backlog can be any of the following:
-Functional or non-functional requirements
-Technical requirements or upgrades
-Bug-fixes
In short any “work” that the team can do for the customer should be routed through the backlog.
Now, we will discuss on product, release or sprint backlog.

5.5 Product release and sprint backlog

Let us quickly understand what is meant by backlog in the context of a product, release or sprint backlog.
-The release backlog is a sub-set of the product backlog and represents the items that the team has agreed to implement within a given release of the product.
-The Sprint backlog is a sub-set of the release backlog and represents the items that the team has agreed to implement within a given Sprint.
-The product backlog may contain epics and stories. The release backlog is typically in terms of stories; whereas the sprint backlog may further break the stories down into specific tasks that are need to accomplish each story or sub-story.
Let us move on to the next slide which talks about user story.

5.6 User story

A user story is the most granular unit of requirements on a Scrum project. The product owner writes the user stories.
It is important to understand that the user story is basically a medium that:
-Helps to gather basic information about the requirements
-Records the requirements at a high level
-Helps development of high level estimation for the work needed
-Defining the acceptance tests that specify how to validate successful completion
The story is the starting point for communication about the details of a requirement and once they are understood and agreed, it represents an agreement between the development team and the customer about what the customer can expect from the implementation.
Now, we will continue looking at user story in the next slide.

5.7 User story

A user story is an atomic requirement that the team works on in an Agile project. As the name suggests, the story describes how the user interacts with the system in order to get his work done.
The 3 alliterated components of the user story (the 3 C’s) are Card, Conversation and Confirmation.
Card is meant to indicate that the story is typically written by hand on an index card about 4 X 6 inches in dimension. The idea behind writing the story on the card is to try and limit the size of each story. When you have to express it in this way, the author of the story has to take efforts to make it less verbose and clearer to the team.
Conversation means that the story should be the starting point of a conversation between the team and the product owner (who typically would write the story). The story should leave the implementation details to the team and have potential to innovate in trying to implement it.
Confirmation means that typically you also need to provide acceptance criteria for the story. Acceptance tests are usually written on the back of the card and help the team understand how they would know that the work done satisfies the requirement.
Another acronym often used to describe desirable attributes of a story is INVEST. Here, I stands for Independent. The stories should be (as far as possible) independent of each other and deliverable as a unit. N stands for Negotiable. It should leave room for negotiation about the nature of implementation. V stands for Valuable, i.e. it should result in some value for the customer. E stands for Estimable, meaning it should be clear enough that the team can come up with reasonably accurate estimate for the work. S stands for Small. The story should not be so big that it cannot be done within an iteration of work. Scrum for instance requires that a story should require no more than 40 man hours of effort. T stands for testable, meaning it should be possible to test the story for correctness based on the description and success criteria provided.
We will now go through an example of user story – formal.

5.8 Example user story formal

A template for a user story is:
As a [role], I want [goal/desire] so that [benefit]
E.g. As an employee, I want to be able to purchase a parking pass online so that I can save time AND be able to park my car safely in the basement.
The role should specify who wants it. The goal/desire should specify exactly what the user wants and the benefit should specify why the user wants it.
A user story will typically be assigned a priority (by the product owner) and a size estimate (by the team). The priority could be the rank (i.e. the desired order in which the story will be picked up for implementation), and the estimates could be the size of the work involved. Estimates are typically expressed in terms of story points or ideal days. The topic of estimation and units of size are covered in lesson-8.
Next, we will talk about the Story card information.

5.9 Story card information

Here is some information that can be captured on the story card per user story. Note that this is not really an iron-clad “prescription” – rather an indicative list that can be customized for your project. A story card should typically contain the following.
-Story identifier (typically a number) and a name.
-A short description (typically no more than a couple of sentences) that describes the feature from the customer point of view.
-Story type (whether the story was requested by the customer or was it a technical story that the team voiced. For example, a feature request typically comes from the customer, but a story to re-factor the code or support a new version of a hardware/software platform may come from the team).
-Estimated work effort (this will be filled in by the team with the amount of effort required to deliver the story).
-Estimated value points (this indicates how much “value” it delivers to the customer).
-Requirements uncertainty (how much variability can be expected in the requirements – sometimes called the “exploration factor”).
-Story dependencies (if a story implementation depends upon other stories).
-Acceptance tests (typically written on the back of the card – it indicates how the story should be tested).
Let us now look into the points which are required to complete a feature.

5.10 Multiple stories may be required to complete a feature

As we discussed earlier, a “feature” is what the customer would typically request and understand. The team (along with the Product Owner) needs to further break this down into user stories that are independent and deliverable as a unit.
A feature may typically contain one or more stories. For example, let us say that the feature desired by the customer is “As a credit card analyst, I need the ability to check a customer’s credit rating”.
In order to achieve this feature, several requirements need to be met. For example:
-The ability to check prior payment history
-The ability to check the credit bureau status
-The ability to calculate an internal credit score based the prior payment history and the credit bureau status.
All the stories contribute to the completion of the feature. A story point is a unit of measure for expressing the “size” of a user story, feature or any other piece of work.
In the next slide, we will learn about Epics.

5.11 Epics

An “Epic” is a way of grouping stories together –either based on a higher level goal or by simply aggregating or grouping a large number of stories together.
An example of an epic could be “Improve scalability”. Within this epic, you could bunch all the stories that are required to accomplish the work of improving scalability. For example, it may include stories to tune the database queries, support multi-threading, etc.
Let us now learn how to write good stories in the next slide.

5.12 Writing good stories

Writing good stories is an art and a science. It needs to be clear to the team what is required and at the same time you need to let the team decide the implementation details by innovating.
A good template to use for writing stories is:
As a [role] I can [feature] so that [reason]For example a story in this template could be: As an account holder, I can transfer money online, so that I can save time by avoiding a trip to the bank.
Make the stories small and use 3” X 5” index cards so that you don’t have to write too much.
Another good practice is to make the story testable by providing acceptance criteria.
Given [context] AND/OR [more context] When [event] Then [outcome] AND/OR [other outcomes]
For example: Given that account balance is negative and no direct deposit is scheduled for that day, if the account holder tries to withdraw money, then the bank will deny the request and send the account holder an alert.
While writing stories, imagine a user scenario (use case) and think of all possible paths the use case can take. Then write the stories to connect all the dots.
Now, we will move on to the next slide and discuss on Splitting user stories.

5.13 Splitting user stories

A user story should be small (typically no more than 40 man hours of effort). Keeping stories small is important to build them within a Sprint, incrementally and collecting feedback along the way.
However on the flip side, it requires the product owner to take considerable efforts to put the requirements in the form of small, granular stories. So let us now proceed to look at various ways in which the product owner can split up larger stories into smaller stories.
We will understand how to split stories, based on the big picture, in the next slide.

5.14 Splitting user stories (big picture)

One way of splitting stories would be based on the big picture. For example:
-Research v/s action: If a story is too complex and requires some amount of research to be done to determine the approach, it may be worth writing a “research story” and assign a certain amount of time to conduct and conclude the research.
-Spike v/s implementation: Even if the approach is clear, sometimes the feasibility needs to be established and the team needs to develop familiarity with the approach to be able to reliably estimate and carry out the work. In such cases, the familiarity is enhanced by working on a “spike story”, which involves writing some sample code to establish feasibility and prove a concept to gain more understanding.
-Main flow v/s alternate flows: It makes sense that you would build the main logic flow first, so make that a separate story and then build the alternative (or exception) flows as part of other stories.
-Buy v/s build: Sometimes the story can be implemented by simply re-using an off-the-shelf component that can be bought or borrowed. You can spend some time to explore the make v/s buy decision.
Let us now talk about Splitting user stories, based on user experience.

5.15 Splitting user stories (user experience)

Another way of splitting stories is based on the user experience. For example:
-Batch v/s online: First implement the logic to execute in a batch mode and then make it online (add the user interactions)
-Single user v/s multi-user: First only cater for a single-user system and later on add the complications of handling multiple users, concurrency, etc.
-API only v/s user interface: First expose a programmatic interface (API) and then add the user interface to make it user friendly.
-Generic UI v/s Custom UI: First use available components to build something quickly, then add the logic to customize the UI.
-
Now, we will look into some other ways to split user stories.

5.16 Splitting user stories (Others)

Here are some other ways of splitting user stories.
-Static v/s dynamic: Initially use static or cached information, and then worry about dynamic or run-time changes.
-Ignore errors v/s handle errors: The basic implementation can choose to ignore some errors and add the sophisticated error handling as part of later stories
-Transient v/s Persistent: Initially let the data be transient and then think about how to persist the data.
-Low fidelity v/s high fidelity: Initially start with a low fidelity or quality deliverable, and add the quality as you go on.
-Small scale v/s large scale: Start with a small/pilot implementation and then expand to the real life and larger implementation
-Unreliable v/s reliable: Perfect uptime is expensive – do not try to build it in one go. Initially some amount of unreliability may be OK, and then try to make it perfect in later stories.

5.17 Quiz

Let us quickly test our understanding of this lesson through this quiz.
Which of the following is the MOST inappropriate requirement to put in the backlog?
A-The system should provide a response time of 0.25 seconds
B-The system should produce a report of all transactions done during the day
C-The system should be implemented using the Oracle database
D-The system should work properly on Internet explorer, Chrome and firefox
Answer is C: The technical and implementation details should be left to the team. The product owner should focus really on providing the requirements.
What is the maximum size of a story in Scrum?
A-5 may days of work
B-20 story points
C-8 ideal days
D-5 days development and 2 days testing
Answer is A: A story in Scrum should take no more than 40 man hours of total effort.
Which of the following items could be on the product backlog?
A-Functional requirement
B-Re-factoring activity
C-Bug-fix for customer defects
D-All of the above
Answer is D: Anything that adds value to a customer or reduces customer pain is a valid item to have on the product backlog.
Who should write the acceptance criteria for a user story?
A-Development team
B-Product owner
C-Test team
D-Scrum Master
Answer is B: The product owner is in the best position to determine the acceptance criteria (i.e. what would make the story successful).
We thus end this lesson on Scrum Artifacts. We hope that this has been a pleasant experience for you. Let us move on to the next lesson. The next part covers the sixth lesson of this course which is about Scrum Best practices.
Happy learning!