SCRUM
I dag
• Hvad og hvordan?
• Hvad er SCRUM?
• Hvad er User Stories?
• Hvordan skriver man en (god) User Story?
• Hvordan arbejder man med Product Backlock?
• Hvordan arbejder man med Sprint Backlock?
• Vi øver os på ”IT-casen”
Learning Objectives for Scrum
Knowledge of Scrum basic process model
How to document and estimate customer requirements
How to turn these requirements into an operational format the developers can use to control their daily work
How to monitor and manage the development effort
(How to calculate team velocity, meaning how much work a team can handle in time-boxed period)
How to work in an iterative manner where software is build piece by piece
Scrum in a Nutshell
Split your work into a list of small, concrete deliverables.
Sort the list by priority
Estimate the effort of each item
Source: Kniberg ” KANBAN AND SCRUM – MAKING THE MOST OF BOTH”
Scrum in a Nutshell
After each iteration
Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release
Optimize the process by having a retrospective after each iteration.
Source: Kniberg ” KANBAN AND SCRUM – MAKING THE MOST OF BOTH”
Product Backlog
The agile product backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product
The Product Backlog
A prioritized list of everything that might be needed in the product:
Requirements, features etc.
Things that the customer wants, described using the customer’s terminology.
Product Backlog Item
Product Backlog Item - Often called (user) story, or just PBI.
Examples of user stories
As a user, I want to upload photos so that I can share photos with others.
As an administrator, I want to approve photos before they are posted so that I can make sure they are
appropriate.
Product Backlog - Living document
The Scrum Product Backlog is changed throughout the whole project.
If needed, new requirements are added and existing requirements may be modified, defined in more detail or even deleted.
Requirements are no longer frozen early on. Instead the final set of requirements within the Scrum Product Backlog is also developed iteratively, together with the resulting software.
This is different to traditional requirements engineering but allows maximizing customer value and minimizes development effort.
Product Backlog - Different level of details
The requirements in the Scrum Product Backlog have a different granularity.
Only those requirements that shall be implemented during one of the next sprints are defined in greater detail and everything else is more coarse-grained.
The simple reason for this is that it does not make sense to invest time and effort into the specification of these
requirements, as most of these requirements will have changed anyway until implementation starts.
Product Backlog
The Scrum Product Backlog is ordered
All entries are prioritized and the Scrum Product Backlog is ordered.
The Scrum Product Owner with the help of the Scrum Team does the prioritization.
Added Value, Costs and Risks are the most common factors for prioritization.
With this prioritization the Scrum Product Owner decides what should be done next.
Who is Responsible for Product Backlog?
The Product Owner
Represents the stakeholders, i.e. the voice of the customer.
Is responsible for maximizing product value
Is responsible for managing the PBL:
Creating Product Backlog items (user stories)
Prioritizes the items in the Product Backlog
Ensuring the Development Team understands items to the level needed.
Scrum Roles
Product Owner
Responsible for the business value of the project
Development Team
Self-organizes to get the work done
Scrum Master
Ensures that the team is functional and productive
Scrum Master
The Scrum Master is the process owner
Responsible for ensuring Scrum is understood and enacted
Helps the team perform at their highest level
Protector of the team (coach)
Scrum Meetings - Flow
Scrum Flow
User Stories
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.
User Story
… is short, simple description of a feature told from the
perspective of the person who desires the new capability (typically user or customer)
User stories can be written informally:
Registered users can reset their password
Or use a bit more formal template
As a registered user,
I want to reset my password,
so that I can get back into the site if I forget my
password
Acceptance Criteria
Bring the project from ”It Works as Coded” to “It Works as Intended”
Are conditions that a story must satisfy to be accepted by a user, customer or other stakeholder (PO in Scrum)
Are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional
requirements
Functional example: When a user clicks on the ‘Reports’ dropdown, a list of available reports will be displayed.
Non-functional example: Form edit buttons will be blue, and Form workflow buttons will be green.
Source: http://www.seguetech.com/blog/2013/03/25/characteristics-good-agile-acceptance-criteria
Example
User story: As an Administrator, I want to be able to create User Accounts so that I can grant users access to the system
Acceptance Criteria
1. If I am an Administrator, I can create User Accounts.
2. I can create a User Account by entering the following information about the User: a. Name, b. Email address, c. Phone Number d. License Number (Power/Basic/None), e. Account Status (Active/Inactive), f. Reports to
(from a list of "Active" Users)
3. I cannot assign a new User to report to an “Inactive” User
4. I cannot assign a new User to report to a User if it creates a cyclical relationship (e.g., User 1 reports to User 2 who reports to User 1 5. The system notifies me that it sent an email to the new User's email
address, containing a system-generated initial password and instructions for the person to log in and change their password.
6. I am able to verify with the intended recipient of the email that it was received.
Source: http://www.seguetech.com/blog/2013/03/25/characteristics-good-agile-acceptance-criteria
Så er det jeres tur!
Identificer og beskriv User Stories for ”IT-Casen”
Beskrives på formen AS a …, I want to …., so that……
Påfør Acceptence Criteria
Estimate
Agile Estimation
Agile estimation is much about setting the expectations and about the time required to complete the software among the stakeholders, the team, and the organization’s management.
If those expectations are not realistic from the beginning of the project, the stakeholders will not trust the team.
Estimating is about reducing the uncertainty to a minimum,
measuring the effort needed to complete the tasks at hand and at the same time taking the complexity of the tasks into account. In order to have a basis for our estimation, we apply a range of tools and techniques that takes uncertainty, effort and complexity into account.
Estimation challenges
Ambiguous/changing requirements are hard to estimate.
Difficult to predict what exactly will be delivered when.
Estimating takes too long and we still don’t get it right.
Estimates are provided by the wrong people (not the ones doing the actual work).
Software projects are unique and ambiguous, hard to provide exact estimates.
Business customers promise unrealistic deadlines then tell the team to make it work.
Commitments are signed based on high level estimates.
Fixed Scope, Time, Budget!
“Estimates” are expected to NOT Change.
Estimation tips
Don't estimate alone
Estimate in a range not in exact numbers
Add some documentation to the estimate
Make the triangulation (compare) with the user stories
Use historical data for et estimate
Story Estimation Technique - Relative sizing
The concept of relative sizing
is to estimate the size of a
function or user story based
on the size of another one.
Story Estimation Technique - S, M, L and XL
S, M, L and XXXXL
Each estimator have four cards S, M, L and XXXXL (epic)
Each estimator privately selects one card to represent their estimate for a story. All cards are revealed at
the same time
If consensus, that will be the estimate
If not, discussion will lead to
re-estimation until consensus
1. Individual stories are presented for estimation.
2. After a period of discussion, each participant chooses from his own deck the numbered card that represents his
estimate of how much work is involved in the story under discussion.
3. All estimates are kept private until each participant has chosen a card.
4. Finally, all estimates are revealed and discussion can begin again.
Planning poker is a full planning
process that combines estimation with identifying the scope of the project and the tasks required to complete the
project.
Similar to relative sizing, planning
poker is an estimating technique used to achieve consensus on work
estimate.
Story Estimation Technique - Planning Poker
Sprint Backlog
The sprint backlog is a list of tasks identified by the Scrum team to be completed during the Scrum sprint.
Sprint Backlog
Within the Sprint Backlog all activities required to complete the committed entries from the Scrum Product Backlog are stored. All entries have to be estimated on a person-hour base in order to track progress and remaining efforts.
The Sprint Backlog is a living artifact and is updated on a daily base. If a team member starts to work on an activity his name is recorded within the sprint backlog. New activities can be added to the Sprint Backlog during the Sprint. At the end of the day all remaining efforts are updated and this defines how much work is left until the Sprint Goal is reached. The Definition Of Done
is used to decide if an item is done or not.
The Sprint Backlog can be kept electronically within e.g. an Excel-Sheet or with cards on a task board. The latter has some advantages (e.g. transparency and easy access) but add additional complexity if the Scrum Team is distributed over multiple sites.
Sprint Backlog
Contains committed stories negotiated between the team and the Product Owner during the Sprint Planning Meeting
Initial tasks are identified by the team during Sprint Planning Meeting
Team will discover additional tasks needed to meet the fixed scope commitment during Sprint execution
Which stories to include in sprint?
Team decision based on: Scope question example – “does this ‘delete user’ story include going through each pending transaction for that user and canceling it?’” In some cases the answers will be surprising to the team, prompting them to change their estimates
In some cases the time estimate for a story won’t be what the product owner expected. This may prompt him to change the importance of the story. Or change the scope of the story, which in turn will cause the team to re-estimate, etc, etc
Sprints
Story
Splitting story into tasks (examples)
As a online store owner, I want to Read (view) my products so that I can review what is current available on my site
1. Create database table
2. Populate table with a few sample data 3. Create select SQL script
4. Create UI for viewing my products
5. …6. Create automated functional tests for viewing functionality
Tasks
Stories
Deliverable things at PO (business value) level
Tasks
Non-deliverable things that PO doesn’t care about.
Sprint Backlog Format
Burndown Chart
Tracking progress during sprint.
The graph shows, each day, a new estimate of how much work remains until the team is finished.
Literature
Henrik Kniberg Scrum and XP from the Trenches:
