[email protected]

agile SCRUM

1. COMP 1807
Matt Prichard
Agile Development with SCRUM
Week 5 –Events and Artifacts Part 2

2. Last week -Remember ?

4. This week
Continue with the Product Backlog and user stories
•Breaking down Epic user stories
•User stories Estimation (playing the Planning Poker game)
•Minimum Viable Product (MVP)

6. User Stories Recap

7. Quick and simple way to describe how a user will use the software to be
developed.
As a <type of user>, I want <some goal> so that <some reason>
Between one and four sentences long (written in Story cards 3x5 index cards)
Describe the WHO, WHAT, WHY
Describe HIGH LEVEL ACCEPTANCE CRITERIA
Define their DEFINITION OF DONE!
The tool to describe the Product Backlog Items

8. An Epic User Story usually covers large amounts of functionality
Epic User Stories should be broken down into smaller user stories which are more easily
estimated.
Huge lists of acceptance criteria is an indicator of an EPIC STORY
Epic User Stories

9. “As a user I can search for jobs, so that I can find a job of my liking.”
Are we now able to start coding and testing with only that as guidance?
Where are the details?
•What values can users search on? County? City? Job title? Keywords?
•Does the user have to be a member of the site?
•Can search parameters be saved?
•What information is displayed for matching jobs?
Epic User Story Example

10. Many of these details can be expressed as additional smaller stories.
Better to have more stories than to have stories that are too large (EPIC).
Why?
•Easier to estimate
•Easier to build and get “DONE” within a Sprint
•More difficult for things to go wrong
Every item in the product backlog should take between 1-5 days of effort each
to get “DONE” (some people say 1-3 days as well).
Epic User Story Example 2

11. Larger Stories are more likely to spill over
into the next Sprint.
Slightly bigger than 5 days may not be a problem but if
Stories are 10 or 15 days of effort then problems with getting
them “Done” are much more likely.

12. Breaking down Epic User Stories
A user I can search for jobs by attributes like
location, salary range, job title, company
name, and the date the job was posted.
A user can search for a jobA user can view information about each job
that is matched by a search.
A user can view detailed information about a
company that has posted a
job.
EPIC
Smaller User Stories

15. A user I can pay with Visa
As a user, I can pay for my flight
with my credit card VISA,
MasterCard, Diners Club, or
American Express.
A user I can pay with Mastercard
EPIC
Smaller User Stories
A user I can pay with DinersClub
A user I can pay with American Express

16. Estimating work

17. T-shirt sizing –Small/Medium/Large/XL/XXL
Quick and easy –often used for Epic stories

18. Story Points with Planning Poker –Most popular technique
§Quick and easy to do –purely relative
§Removes disparity of different skill levels.
§Represent the effort to develop a story. This includes:
•The amount of work to do
•The complexity of the work
•Any risk or uncertainty in doing the work
Estimating user stories
Development team is responsible for ALL estimates. Product Owner may
influence the team by helping it understand and select trade offs

19. Story Points rather than time –why better?
1.Easier and quicker to compare the relative size of things than making an
absolute estimate in days –Gets the team talking about estimates.
2.Development Team members with different skills and working at different
speeds can agree on an estimate with Story Points
3.Estimates in days is more likely to be interpreted as a fixed delivery date by
stakeholders than a Story Point estimate. This can put the quality of the
deliverable at risk.
At this stage of the process, we know that all estimates might be wrong and might
have to be changed as we start working on the product.
To avoid mistakes, it’s easier to estimate with story points rather than with days.

21. A consensus based estimating technique.

22. Anything at the lower end of the scale is a small
piece of work right through to a massive top end.
Anything that is too hard to handle should be a
100.
A consensus based estimating technique.
Being effective with user stories estimation comes with experience and practice –
the more Sprints the team works together, the easier it would be to track their
velocity and how much progress they make and therefore the meaning of those
user story points

23. Product Owner reads a story card describing a feature to the
Dev Team
1.Each dev team member hold a deck of planning cards with values 0,½,1,2,3,5,8,13,20,40,100
•These represent the number of story points
•Anything at the lower end of the scale is a small piece of work right through to a massive epic.
2.When the feature has been fully discussed each member selects a card to represent their
estimate.
3.All cards are then revealed at the same time
4.If all have selected the same value then this becomes the estimate
5.If not, then discussion happens
6.High and Low estimators should share their reasons and then the same process follows again
until consensus is achieved.

24. Product Backlog after ordering and estimation

25. Stories with points 13, 20, 40, 100 are Epic and should be broken down.
•When broken down the resulting smaller user stories usually add up in
points with the Epic point estimation.
The stories with 2,3,5,8 points are usually included in the Sprint.
A 2 point story should approximatelyrelate to 1-2 days of work
5-15 stories per Sprint is about right (20 might be an upper limit depending
the work –e.g. a web team doing lots of small changes, 25 maybe for a
maintenance team working on small defects)

26. Don’t know -need more info
Can’t be done -infinity
Need a break –coffee time
Planning poker apps

27. MVP

29. Creating the Product Backlog aims to produce a summary list of what’s needed
to deliver the Product Vision. One way to do this would be to think each step of
the customer journey to produce a workflow. –Buy a cinema ticket
Added together these items deliver the functionality of the step and are often
referred to as feature groups.
Some of the items will be essential and some nice-to-haves.
Organisingtheproductbacklog

30. 1.Product Owner ordersthe Backlog items/stories based on Value/Benefit
2.(Moscow is used, but also use numbers to indicate priority with 1 the most urgent)
3.Development team estimate the user stories
Defining Primary Functionality -MVP

31. Once the Ordering and Estimation is completed, the Minimum Viable
product can be identified.
MVP is the smallest amount of functionality to test or validate the viability
of an idea –get customer feedback early.

32. Apple Ipod
•Focused on the Minimum Viable product
•Received feedback and improved it in every release
•Speed to market
•Simple solution –good quality product
•Simplicity means better emphasis on quality
Example of MVP with Apple

33. To identify the MVP we follow the 60% to 40% rule.
Using the 60% of the product backlog stories (all the Must haves for
our MVP) provides us with the minimum number of features that we
can have for the first release.
•The Must have features shouldn’t be more than 60%
•If more, then we really need to re-consider what is a Must Have or
could have with the Product Owner
The other 40% is contingency (should haves and could haves) –
allowing the team to fail the 40% but still achieve enough (the MVP).
MVP summary

34. •Breaking down Epic user stories
•User stories Estimation (playing the Planning Poker game)
•Organising the Product Backlog based on the user’s journey (workflow) and
identifying the features/user stories under each step.
•Pin down that MVP! Everything rests on getting it right and out there
quickly.
Next week –Continue with Scrum Framework in Detail Part 3 –Sprint
Planning and Spring Backlog-The Kanban Board, The Sprint, Burndown
charts, Velocity and Product Increment
Wrap Up

35. ?