Useful definitions
What is Agile?
-
Agile - a project management methodology that uses short development cycles called Sprints to focus on continuous improvement in the development of a product or service. This methodology helps modern development teams in responding to the unpredictability of building software and applications.
What is Scrum?
-
Scrum - is a most popular agile product development framework —a mix of different values, team roles, and rituals. Scrum is a framework for developing, delivering and growing complex products
What are User story in Agile (Scrum)?
-
User Story- a description of a product, feature or requirement from a user's perspective.
What is Epic?
-
An epic - is a large user story that it can be split into smaller user stories. It is usually a complex feature/part of the product.
What is Product Backlog?
-
Product Backlog - a set of items that describe the features in a product. This usually consists of user stories written on story cards. It can be kept physically or digitally.
What is Sprint in Scrum?
-
Sprint- a period of time (usually 2 or 3 weeks) within which a team builds a releasable increment of a product. Sprint can be defined as a timeboxed iteration of a continuous digital product development cycle.
What makes a good user story in Agile?
The "INVEST" principle
-
Independent - each User Story should be self-contained from all the other User Stories in the Product Backlog. (In other methods requirements weren't clearly separated from each other within the Project Specification).
-
Negotiable - the team is able at all times to negotiate what is on a User Story by having a discussion with a Product Owner.
(Traditionally there was no collaboration and communication within a team).
-
Valuable - every User Story should actually have a value. (One of the key things is making the reason why the story should be built and that reason should detail the ROI of the business or the value).
-
Estimable - every User Story should be written in a way that each team member can read it, understand it and put an estimate on it.
-
Small - a whole concept of Scrum is to build projects in small increments; this means that you can deliver small pieces of value through the lifetime of a project (get something that can be taken to market after every iteration/sprint). Larger problems must be broken down into smaller ones.
-
Testable - a piece of functionality should be "Done"; usually a feature is not done until it is not tested and a tester has verified that the feature meets the quality standards. (Anything that is delivered has a high standard of quality).
The "3 Cs" principle in Agile
Every good user story should have these elements, known as the three C’s principle:
-
Card - User Stories are captured on story cards. The team reads the card before building the feature.
-
Conversation - discussions between team members, team members and Product Owner, product owner and stakeholders or conversations between all 3 to make sure that the product is being built according to the requirements.
-
Confirmation - the Product Owner confirms that everything has been done exactly the way he wanted it to be.
The three C’s principle is a very common practice in modern agile project management.
Who writes User Stories in Agile?
Anyone in an Agile team can and should write user stories, however, the Product Owner is responsible for making sure that the User Stories are written and that the product backlog is managed.
The Product Owner will usually communicate with the team regularly to make sure this happens. The team will usually collaborate with the Product Owner and often write cards that the Product Owner prioritizes in the backlog.
Product owners should be focused on the business value each story provides to the user, they are usually considered as "business" or "client" advocates.
Agile Cards (or Agile planning poker)
Physical cards
User Stories are written on 3 by 5 inch cards. The description goes on the front, Acceptance Criteria on the back.
Cards in Jira software
There is a plugin/functionality in Jira Software for a more scrum-like look and feel. Read more in JIRA's documentation.
User Story
"3 Rs" concept
How to write a User Story using the "3 Rs" concept:
As a role
I want requirement
so that reason/ROI
- The role explains what type of user the feature is aimed at.
- The requirement explains what the user should be able to do.
- The reason/ROI explains what the value is to the user/business.
Acceptance Criteria
Its purpose is to articulate precisely when the User Story is "Done" from the Product Owner's perspective. They should translate into "acceptance tests" that a QA tester can use to verify the quality of the feature. The tester can be involved in writing them but it is a Product Owner's responsibility to produce them.
Acceptance Criteria
A user should see/be able to:
-
Acceptance Criteria 1
-
Acceptance Criteria 2
-
Acceptance Criteria 3
Edge cases (other scenarios)
-
Edge Case 1
-
Edge Case 2
-
Edge Case 3
Epics
- Larger User Stories are called Epics.
- Epics usually cannot be done in one Sprint.
- Epics can be broken down into several User Stories.
Themes
- A theme is a collection of Stories with a shared attribute.
- Themes may not be done in one Sprint unless they contain very small Stories.
- Stories in the theme are completed in their relevant iteration/sprint (don't need necessarily to be completed within the same Sprint).
User story examples
User Story
As an F1 game player
I want to see a circuit map
so that I know where I am on the circuit
Acceptance Criteria
An F1 game player should se a track that:
- as closely as possible resembles the shape of the F1 track in the game
- consists of a graphical circuit line that fits within a 3 by 5 proportioned box
- has a small dot that represents the game player's car
- the dot should move in relation to and in proportion to the game player's position on the track
Edge cases
- If the car blows up, the dot should turn red for 1 second then disappear
Epic
As an F1 game player
I want (to see) an Options Screen
so that I can choose the driver I want to use
-
User Story 1: As an F1 game player I want (to see) an Options Menu so that I can choose the driver I want to use
-
User Story 2: As an F1 game player I want (to see) the Image Holder for a driver so that I can see the driver I want to use
Theme
As a sports fan
I want a group of Sports pages
so that I can see the top 10 news stories for each sport
-
Sports homepage: As a Soccer Fan I want a Football Home Page so that I can see the top 10 football news stories
-
Sports homepage: As a Baseball Fan I want a Baseball Home Page so that I can see the top 10 baseball news stories
You can use the above examples as a User Story template for jIRA or similar platforms.
When to split Stories?
- When it cannot be completed inside the iteration/sprint.
- When you want to get accurate time estimation.
Teams really need Stories to be in manageable size in order to estimate them well.
How to split Stories?
-
Don't meet performance constraints - we often have non-functional requirements; there are requirements that must be met, however invisible necessarily to the User (not something that the User can see, but that can affect the User), so we can remove them from a Story in a given iteration/sprint and make it easier to estimate and complete inside the iteration/sprint.
Acceptance criteria: The user should be able to load the page in less than 30 milliseconds
-
Remove cross-cutting concerns - an example of a scenario when we have a piece of work that needs to be done for more than one page (error messages, logins etc.).
Acceptance criteria: If there is an unknown error loading the page, the user should see the standard error message "Unknown Error: Currently unable to load this page. Please refresh the page and try again."
-
Separate out into a separate Stories any criteria that is of mixed priority - different acceptance criteria that can be prioritized based on the business needs (is it really needed to complete this part of the Story at
this moment/iteration/sprint).
Acceptance criteria: The user should see an advertisement for the sports channel below each news story, measuring 5 by 2 inches.
When to combine Stories?
- When stories are related and still can be completed within iteration/sprint.
- When you want to prioritize as a group (as long as the above criteria holds).
- Create an Epic if it is too large to fit in a Sprint.
- Create a new Story if it can fit in a Sprint.
- Create a theme if it is a set of related Stories.
Story points in Scrum
Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.
In Agile development, the Product Owner is tasked with prioritizing the backlog - the ordered list of work that contains short descriptions of all desired features and fixes for a product.
Story points estimate the relative effort of work by using a simplified Fibonacci sequence: 1, 2, 3, 5, 8, 13.
The Fibonacci sequence is a series of numbers where each number is equal to the sum of the two numbers that come before it, and usually starts with 0 and 1: 0 + 1 = 1, 1 + 1 = 2, 1 + 2 = 3, 2 + 3 = 5, etc.
Some teams use other measurement scales for story points, but this is a common one.
When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a 2 should be more complex than a story that is assigned a 1. It should also be less complex than a story that is estimated as 3 story points, and so on.
Because story points represent the effort to develop a story, a team's estimate must include everything that can affect the effort. That could include:
- The amount of work to do
- The complexity of the work
- Any risk or uncertainty in doing the work
Example: Items in the Backlog
- Item 1 (e.g. points: 1)
- Item 2 (e.g. points: 2)
- Item 3 (e.g. points: 3)
- Item 4 (e.g. points: 5)
- Item 5 (e.g. points: 8)
- Item 6 (e.g. points: 13)
We are Creitive, digital product agency. If you want to learn more, check out our Agile Product Development Services
