SlideShare une entreprise Scribd logo
1  sur  30
Télécharger pour lire hors ligne
Practical Guide
to Scrum
by Pavel Dabrytski
COPYRIGHT AND CONFIDENTIALITY NOTIFICATION: The information contained in this document is proprietary information which is protected by copyright and at law. All rights
are reserved. No part of the information contained in this document may be copied, reproduced, disseminated, transmitted, transcribed, extracted, stored in a retrieval system or
translated in any form or by any means, without the prior written consent of IQ Business. The information contained herein is confidential to IQ Business.
version 2.0. 7 April 2014.
Huge thank you to Ayanda Mkize, Biase De Gregorio and Hannah Ward for reviewing the guide and leaving me hundreds of review notes!
Agile
3
Agile Manifesto and ScrumValues are the heart of any agile implementation
Individuals and interactions over Process and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
Agile Manifesto
Definition of Agility
“Agility is the continued
readiness “to rapidly or
inherently create change,
proactively or reactively embrace
change, and learn from change
while contributing to perceived
customer value (economy,
quality, and simplicity), through
its collective components and
r e l a t i o n s h i p s w i t h i t s
environment.” Conby 2009.
Keys to a successful Scrum team?
 Roles of scrum master and product owner are performed by the
right people
 Scrum master and product owner have enough time to perform
their duties
 Development team is co-located
 Members of the development team are dedicated to that team
(100% allocated)
 Development team is cross-functional
 Development team is self-organised
Agile principles
1. Early and continuous delivery of valuable
software
2. Welcome changing requirements
3. Deliver working software frequently
4. Business people and developers must work
together
5. Motivated individuals produce the best results
6. Face-to-face conversation is the most valuable
7. Progress is measured by working software
8. Enforce a sustainable development pace
9. Technical excellence enhances agility (and
quality)
10. Simplicity
11. Self-organising teams produce the best
solutions
12. At regular intervals, the team adjusts its
behavior to become more effective
Copyright 2014 IQ Business
Scrum Framework
4
This picture represent the full Scrum process
Copyright 2014 IQ Business
Product Vision
5
Product vision is a short statement which describes end goals, objectives and benefits of the product
Who owns vision?
Moore’s product vision model
FOR: «target customer»
WHO: «needs»
THE: «product name»
IS A: «product category»
THAT: «product benefit. Reason to buy»
UNLIKE: «competitors»
OUR PRODUCT: «differentiation or value
proposition».
Product owner. However everyone contributes
towards the product
vision.
Example
FOR a mid-sized company's marketing and sales departments
WHO need basic CRM functionality,
THE CRM-Innovator
IS A web-based service
THAT provides sales tracking, lead generation, and sales representative
support features that improve customer relationships at critical touch points.
UNLIKE other services or package software products,
OUR PRODUCT provides very capable services at a moderate cost.
?
Absolutely! Product vision should reflect
current business conditions (market, budget,
capacity etc.). However, constantly changing
vision is an indication of a problem.
Product owner together with
stakeholders and the team.
Can vision be updated?? Who updates vision??
Elevator test
“Can you explain your product in the time it
takes to ride up in an elevator?” Moore (2006,
p. 152). Passing this test ensures that your
product vision is clear, engaging, and brief.
!WHEN
WHY
First thing. Before product Backlog.
Product vision is needed to ensure the product is moving in the
right direction, strategies are aligned and that the development
team spends its time creating the right product.
Copyright 2014 IQ Business
Product Backlog
6
Product backlog is a single list of features/requirements for the product, prioritised by value
Product backlog
 Contains features, defects, technical work,
knowledge acquisition
 Ordered by priority
 Prioritised by product owner with help from the
development team and stakeholders
 Physical wall, white board, index cards
and post-it notes (recommended)
 Excel (most widely used)
 Any other electronic tools such as TFS,
VersionOne, Pivotal Tracker, etc.
MoSCoW prioritization
Must have—all “must have” stories form the
minimal viable product (MVP) and good enough
for the first release
Should have—all “should have” stories make
this product competitive
Could Have—all “could have” stories delight
the customer
Won’t Have—All “won’t have” stories aren’t
worth doing. The majority of stories (65%)
should fall into the “won’t have” pile
Tools for product backlog! If team works on multiple projects or products at the
same time, we suggest creating a single team
backlog. The product owner must prioritize work for
multiple projects within this backlog. It will help the
team to keep focused and will save time on scrum
meetings.
Multiple projects?
MoSCow is only one of many. You may look at
Kano, Buy-a-feature, The Product tree and others.
Prioritization techniques!
Backlog iceberg
Backlog Iceberg is an Agile just-in-time technique.
User stories in Product Backlog are stored in
different levels of detail where highest priority (top
of the iceberg) stories are most detailed.
Copyright 2014 IQ Business
User Story & Acceptance Criteria
7
User story is an agile technique to facilitate requirement management
Acceptance criteria—checklist which defines acceptance testing for this particular story
Wrong story format
‘As a BA I will document price history’
 This user story is missing the
actual user role. It is impossible to
identify the person or role who
will benefit from the user story
 This user story doesn’t explain the
reason why completing it is
valuable and beneficial.
!
Story Formats
[Beginner] - Simple statement of functionality which needs to be build.
example: ‘View email history.’
[Classic] - Connextra format: As a <user role>, I want <goal/desire> so that
<benefit>.
example: ‘As a senior support agent I want to view the emails send to the customer, so I
know which communication took place.’
[Advanced] - In order to <receive benefit> as a <user role> I want <goal/desire>.
example: ‘In order to be able to assist customer promptly, as a senior support agent I want
to view previous customer email communication on my agent dashboard.’
Acceptance Criteria Format
[Beginner] - Simple description on how
functionality should work.
example: ‘Only show last 2 emails sent to the
customer’ ‘When pressing “resend email”, show
example of email sent’
[Advanced] - Given <precondition> When
<scenario> Then <expected result>.
example: ‘Given that customer didn’t receive any
emails yet, when agent opens dashboard, then ‘no
previous emails’ message is displayed.’
Definition of Done vs
Acceptance criteria
Definition of done is generic and
applicable to all stories.
Acceptance criteria is specific and is
different for different user stories.
!
Copyright 2014 IQ Business
Definition of Done
8
Definition of done is a checklist of valuable activities required to produce complete software
Definition of done is unique per
team, although it might contain some
elements which are required by the
department, organisation or
industry.
Example
 All development has been completed
 Functionality has been tested by developer
 Unit tests have been completed
 New business functionality satisfies
acceptance criteria in TFS*
 All features have been tested in IE8**
and
IE9**
 Regression tested in IE8**
& IE9**
test
environment
 Code has been reviewed by another
developer
 Story has been reviewed by product owner,
and product owner has accepted all open
issues, if any
DoD per team!
Definition of done may change over time
as the team continues to build the product
and learn from the process. Usually
definition of done is reviewed by the
whole team at one of the sprint events (i.e.
sprint retrospective or sprint planning).
Can DoD change?? Definition of done vs
acceptance criteria
Definition of done is generic and applicable to
all stories.
Acceptance criteria is specific and is different
for different user stories.
!
*- Team Foundation Server
** - Internet Explorer
Copyright 2014 IQ Business
Relative Estimation
9
Planning poker
Planning poker is a consensus-based
technique for estimation. It helps avoiding
the influence of the other participants. Here is
the procedure:
 User story is selected
 Product owner (or scrum master) briefly
explains the story and answers any
related questions (2mins)
 Voting occurs (1st round)
 If the estimates show a large variation, a
further 2 mins should be used to explain
why the estimates should be higher or
lower
 Voting occurs (2nd round)
 If the estimates still show a large
variation, a further 2 mins should be used
to re-explain/justify the estimates
 Voting occurs (3rd round)
 If, after the 3rd round of voting, no
consensus can be reached regarding the
size, the story is placed on hold
What NOT to do
 Don’t allow anyone to shout estimation
aloud before the team estimates together
 Don’t allow anyone in the team or any
stakeholder to override teams decisions
(i.e. ‘come on guys, it is not 40, it is a 3’)
 Don’t take an average of estimates
without having discussions
 Don’t allow people not to vote. Asking
everyone to vote will improve the team’s
understanding of each other’s work
 Don’t assign story points by yourself. It is
always a team discussion
!
 Estimation in relative points has
proven to be quicker
 It removes link between estimating
effort and committing to timelines
 It helps to remove false accuracy
around estimates
Why relative estimation??
Relative estimation is a forecasting technique with a story point as a unit of measure
Modified Fibonacci
Scale is 1 2 3 5 8 13 20 40 100
Estimation in relative points has proven to
be quicker. Also estimation in hours is
prone to further inaccuracies because it is
based on ideal hours.
Time vs points!
A story point cannot be directly converted
into hours. It only shows how much smaller or
bigger the item is compared to other items in
the backlog.
It can be calculated of course, but such
information should be used for release
planning only (i.e. velocity), and not per story
or task .
How much is 1 point??
Velocities and estimates of different
teams are not directly comparable due
to different baselines/team norms.
Comparing teams!
Baseline
When estimating for the first time, se-
lect the smallest story and assign it 3
points. It will become your baseline.
Copyright 2014 IQ Business
Sprint
10
Sprint is a time-boxed event with a goal of producing working product at the end of it
By order of popularity:
 2 weeks
 3 weeks
 1 week
 4 weeks
Sprints should not be longer than 1
month.
Popular sprint length!DOs
 Consistent duration throughout life
cycle of the project
 New sprint starts immediately after
the conclusion of the previous sprint
 Schedule recurring meetings for all
scrum events in team diaries
 Create sprint goals for each sprint
DONTs
 Extend/shorten sprint after it
commences
 Have a couple of days gap between
sprints
 Add changes/stories which might
endanger sprint goal
 Decrease quality of work in order to
finish stories in the sprint
 Split testing and other quality checks
into another sprint
 Start a new sprint on Monday as it will
end on Friday. People are not focused
enough on Fridays
 Don’t create “mini-waterfalls” during
your sprints. In other words 1 sprint of
analysis, 1 sprint of development and
1 sprint of testing
Cancelling sprint
 Only product owner can cancel a
sprint
 All events (sprint review, sprint
retrospective & sprint planning)
should take place in order to
commence new sprint
 There should be no gap between
cancelled and new sprints
 Try to avoid sprint cancellation
 Daily scrum (standup)
 Sprint planning
 Backlog refinement (grooming)
 Sprint review
 Sprint retrospective
Scrum events!
Often sprints are called iterations.
Iteration and sprint are the same
concept.
Iteration vs sprint!
Copyright 2014 IQ Business
Sprint Goal
11
Examples of sprint goal
 In this sprint we will allow users to log-in
to the site, retrieve a forgotten password,
and manage their own profile
 In this sprint we will implement basic
shopping cart functionality including
add, remove and update features
 In this sprint we will integrate VISA
payment gateway into our billing module
and investigate MasterCard gateway
!
Sprint Goal is a short (1-2 sentences) description of what the team plans to achieve during sprint
 Whole team decides on sprint goal together with product
owner, scrum master and stakeholders
 Sprint goal must be realistic and SMART (specific,
measurable, achievable, relevant and timely)
 Sprint goal must not be forced onto the team
 Sprint goal is decided during sprint planning event
Copyright 2014 IQ Business
Sprint Backlog
12
List of user stories, tasks and other activities team commits to deliver in order to achieve sprint goal
 Use different colours for different types of tasks (i.e.
development—blue, impediments—purple, business
analysis—pink), but each team can define their own
standards at visualizing sprint backlog
 Limit number of user stories in progress—it will reduce
amount of user stories carried over into next sprints
 Limit number of impediments in progress—focus on most
serious blockers first
 Agree on maximum period of tome to resolve an
impediment, before it is escalated to broader audience
 Use index cards for user stories and post-it notes for tasks
 A good user story can be done within 3 days and a good task
should take no more than 1 day
 Add your retrospective actions to sprint backlog as well
 Use ‘Super Sticky’ post-it notes
Tips!
Copyright 2014 IQ Business
Impediments
13
Problems with impediments
 If the impediment backlog lives in the mysterious
black book of the scrum master, you have a problem
 If your impediment backlog does not change you
have a problem
 If your impediment backlog is empty, you have a
problem
 If you have an impediment backlog with a growing
number of active impediments, you have a problem
 If the scrum master resolves all impediments himself/
herself, you have a problem
!
Impediment is anything which is standing in team’s way towards achieving the print goal
Tips for dealing with impediments
 Make the impediments visible—use special colour
post-it notes for them
 Search for impediments. Look out for impediment
words (‘still waiting’, ‘not available’, ‘hopefully’,
‘wish’, ‘guess’, expected’, I thought’, ‘try’)
 Limit the number of impediments. Select 3 biggest
ones and put a big red dot on each of them. It will help
the team focus
 Help the team to resolve impediments
!
4th standup question
One of the techniques to identify more impediments is to
ask a 4th question at standup.
‘How confident are you that you will achieve sprint goal?’.
If it is anything less than 100%, by asking why, you will
discover an impediment.
‘How can we go faster?’
Is another question to bring out impediments to the
surface.
? Global vs local impediments
Global impediments need attention of your
stakeholders and relevant stakeholders should be made
aware of them as soon as possible.
Local impediments are within team’s capability to
resolve.
!
Copyright 2014 IQ Business
Sprint Burndown/Burnup
14
Sprint burndown/burnup are charts which represent progress of work during the sprint
 Have user stories
 Estimate each user story together with your team in story points
(1 2 3 5 8 13 20 40 100)
 Calculate total number of story points in sprint
 Calculate total number of working days in sprint
 Should be updated by the team at the same time every day
What do you need to create one??
Points are reflected in the chart once a
whole story is complete as per definition
of done. In other words, if a story is not
complete, it is calculated as 0.
No points are assigned to tasks as an
individual task doesn’t usually carry
business value on its own.
Story points!
Both charts represent the same information.
Burndown displays work outstanding Burnup displays work done
Copyright 2014 IQ Business
Daily Scrum [Standup]
15
Daily Scrum is an event to synchronise the team and plan for the next 24hrs
What else to do at standup/after standup
 Review impediments
 Update burndown/burnup chart
 Make decisions
 Update sprint backlog (i.e. move post-it notes, add more tasks)
!3 Standup Questions
Each team member should answer these 3 questions:
 What did I do yesterday that helped the
development team meet the sprint goal?
 What will I do today to help the development team
to meet the sprint goal?
 Are there any impediments that prevent me or the
development team from meeting the sprint goal?
WHEN
WHY
Every day
Synchronise activities and create a plan for the next 24 hours
HOW LONG 15 minutes
WHO Mandatory: development team
Optional: scrum master, product owner, stakeholders
If you feel that a conversation is going on
for too long and other team members
start to lose interest, you can add the
issue to the parking lot and ask those
involved to discuss it right after the
standup.
Meet after?
Copyright 2014 IQ Business
Sprint Planning
16
Sprint Planning is an event to plan work for the sprint
Typical agenda
PART ONE: WHAT
1. Discuss team capacity
2. Identify sprint goal
3. Identify user stories needed to achieve
sprint goal
4. Clarify requirements for these user
stories
5. Update product backlog: split, delete,
combine, move stories
6. Estimate user stories
7. Commit to sprint goal and user stories
PART TWO: HOW
1. Decide how to achieve the sprint goal
(design)
2. Clarify requirements further
3. Negotiate trade-offs
4. Break down stories into tasks
5. Update Scrum board
First day of each sprint
Plan work; obtain commitment for the sprint; eliminate other
meetings; manage stakeholder expectations; mitigate risks
2 hours for every week of sprint
Mandatory: development team, scrum master, product owner
Optional: stakeholders
Product owner should come to sprint
planning prepared to talk about 2 sprints
worth of work.
Product owner?
 Product backlog and its complexity
 Stationery (post-it notes, index
cards, markers)
 Team capacity (how much time will
team have to do the work): leave,
public holidays, training etc.
 Business conditions
Prerequisites
Copyright 2014 IQ Business
WHEN
WHY
HOW LONG
WHO
Sprint Review
17
Sprint Review is an event for the team to show what they accomplished during the print and reflect on
current state of the product
Last day of each sprint before sprint retrospective
Demonstrate results of sprint; discuss product and adjust
product backlog; collaborate on the next goals; review
timeline, budget, release plan
1 hour for every week of sprint
Mandatory: development team, scrum master, product own-
er, stakeholders
 Say NO to slides, show working
software instead
 Say NO to showing incomplete
stories
 Say NO to scrum master or product
owner doing demo, it is better for
development team to demo their own
work
Say NO to...!
 List of complete/incomplete stories
 Big boardroom with projector screen
 Laptop
 Team needs to prepare for this event
(~ 1 hour)
Prerequisites
Typical agenda
 Review meeting agenda and guidelines
 Team walkthrough of completed functionality with product owner
 Team demonstrates working software to stakeholders
 Team discusses incomplete user stories
 Product owner moves/splits/re-prioritizes the backlog
 Product owner closes the sprint and accepts relevant functionality (if it wasn’t
accepted during the sprint)
 Open actions/impediments are noted
Copyright 2014 IQ Business
WHEN
WHY
HOW LONG
WHO
Sprint Retrospective
18
Sprint retrospective is an event for the team to reflect on current progress and find improvements
Typical agenda
5 stages of retrospective
1. Set the stage
2. Gather & analyze data
3. Generate insights
4. Decide what to do
5. Close the retrospective
Practical example:
1. Each team member around the table
says 3 words about previous sprint
2. Ask everyone to write 3 post-it notes for
‘what went well’ and ‘what can be
improved’ and stick them on the wall
3. Group them into themes
4. Identify the most painful item
5. Brainstorm actions that can be taken in
the next sprint to improve the item
6. Thumb vote on how retrospective went
Last day of each sprint after sprint review
Reflect on current progress; identify improvements
1-1.5 hours
Mandatory: development team, scrum master
Optional: retrospective should be safe place for the team to be
truly open. Beware of inviting anyone outside of the development
team as it might change dynamics of the retrospective.
You can pick up more ideas for your
sprint retrospective at
http://plans-for-retrospectives.com/
Or invite other scrum masters to facilitate
a session for you.
More ideas!
 White board
 Post-it notes
Prerequisites
Make your actions SMART (specific,
measurable, achievable, relevant
and timely).
Assign owners to retrospective
actions.
Put all retrospective actions on
Scrum board (sprint backlog) and
track them as any other work.
Actions!
Copyright 2014 IQ Business
WHEN
WHY
HOW LONG
WHO
Backlog Refinement
19
Backlog refinement is an event to help the team to get user stories ready for future sprints
During sprint, perhaps weekly
Get user stories ready; add detail to user stories; estimate
user stories; identify risks and issues before sprint
planning; update priority of user stories
30 minutes—2 hours
Mandatory: development team, scrum master, product owner
Optional: stakeholders
A good user story is:
Independent / immediately
actionable—ideally can be implemented
in any order
Negotiable—and negotiated
Valuable—to the customer
Estimatable—enough to rank and
schedule it
Small—and with short descriptions
Testable—I could write a test for it
INVEST!
 Product backlog
Prerequisites
Typical Agenda
1. Identify user stories to refine
2. Clarify requirements for these user stories
3. Identify open items/questions for these user stories and assign owners to them
4. Break down user stories which are too big
5. Discuss priority of these user stories and update if necessary
6. Estimate user stories
Copyright 2014 IQ Business
WHEN
WHY
HOW LONG
WHO
20
Scrum Roles
 Cross functional
 Dedicated (allocated 100% to the team)
 Co-located
 Self-organized
 Ideal size for development team is 3 to 9
Development Team3 Roles in Scrum
 Scrum Master
 Product Owner
 Development Team
If person works daily together with
development team towards achieving sprint
goal, then he/she forms part of the team.
Stakeholder or team member?
21Copyright 2014 IQ Business
Scrum Master
 Facilitate Scrum events
 Identify and help to resolve
impediments
 Be guardian of Scrum process
3 Main responsibilities
 Help the team to resolve impediments
 Facilitate Scrum events (prepare, lead, writeup)
 Help team to continuously improve their process
 Maintain Scrum tools (story board, backlogs, charts, etc.)
 Help team to create/maintain definition of done
 Help to create/refine user stories
 Coach team members, consult team members regarding everything agile
 Resolve conflicts within the team
 Help team to make decisions
 Encourage team self-organisation
 Mediate communication between development team and product owner
 Continue personal growth in Agile (user groups, conferences, reading
books and articles, writing blogs)
 Interact constantly with other scrum masters within the organisation
 Help with release planning
 Be familiar with team's work/progress, feedback to stakeholders on team's
progress
 Bring right people together for communication
 Keep in touch with stakeholders regularly
 Give learning opportunities to people within the organisation
 Arrange/capture team policies and agreements, remind the team about
them
 Ask open questions, encourage team members to express their opinions
 Help the team to keep focus
Full list of responsibilities
Can product owner and scrum master be the same
person?
No. The roles have different goals and
responsibilities. Product owner protects interests of
stakeholders and scrum master protects interests of
their development team. Often they play offense-
defense, which is not possible to achieve when one
person combines both roles.
Scrum master vs product owner?
Good scrum master can work with 2-3 teams at the
same time, great scrum master always works with a
single team.
Multiple teams!
22 Copyright 2014 IQ Business
Product Owner
 Own product backlog
 Prioritise work
 Accept/reject work
3 Main responsibilities
 Ensure that the team builds the right product
 Manage ROI and make sure to deliver business benefits
 Responsible for the budget constraints to be met
 Ensure that what the team is asked to build is aligned with what the
sponsor, stakeholders and users want
 Provide a vision for the product
 Provide boundaries to describe the realities within which the vision must
be realised (e.g. time frames, external quality)
 Make sure management, stakeholders, sponsors are informed and the
vision is aligned with their wishes
 Communicate the project vision to the team and motivate the team to
subscribe to the product vision
 Manage stakeholder expectations regarding requirements and project
boundaries (time frames, quality, technical constraints etc.)
 Create and maintain the product backlog (the product owner can delegate
some of the work of writing user stories to a BA but the Product Owner is
still responsible for ensuring that the work is being done and is being
done properly)
 Continuously refine the product backlog
 Prioritise user stories within the product backlog
 Define releases, their goals and sprint goals
 Continuously answer questions to add detail to requirements/user stories
 Accept/reject developed user stories at the end of the sprint (or during
the sprint)
 Communicate about the project within the organisation (e.g. demo
attendance and invites, forecasting, management reporting, sponsor
liaison)
Full list of responsibilities
Product owner is a full time role in many
organisations. We suggest to spend at least 20 hours
per week for each team in order to be able to
achieve desirable outcomes.
How much time do I need?
Backlog owner or proxy product owner is
usually an interim role during Agile
implementation. Person in this role takes
over product backlog management
responsibilities.
In mature teams this roles considered an
anti-pattern as proxy product owner
becomes a middle man in communication
between product owner and the team.
Proxy Product Owner!
23Copyright 2014 IQ Business
Product Burnup
Product burnup is a chart which represents the progress towards completing the product backlog
 Have all requirements included in product backlog ( initially these requirements will be epics/high level features. With time,
product owner and team will refine these epics into more detailed stories)
 All stories and epics are estimated in story points
What do you need to create one??
 Project delivery date, based on historical
velocity
 Average velocity required to finish work by
specific date
 Is project ahead of behind schedule (comparing
ideal and actual burning rates)?
 Amount of carry over stories in each sprint and
its trend
 Velocity per sprint and its trend
Valuable information!
24 Copyright 2014 IQ Business
Release Plan
Release plan shows days of release and epics/high level features to be
realized in this specific release.
Date Sprints Status Description
Release 1 28/01/2014 2-3 Delivered Feature A
Feature B
Integration with system X
Feature C
Patch release 1.2 05/02/2014 4 Delivered Fixes for Feature C
Patch release 1.3 09/02/2014 5 Delivered Fixes for Feature C and A
Release 2 28/04/2014 6-8 Off track Feature D
Migration of data Y
Release 3 15/05/2014 9-10 Feature E
Release as often as possible. It will allow
for early feedback from users and
stakeholders.
First release should be your minimum
viable product (MVP).
How often to release?
Flight Plan (Story Mapping, Critical Path)
is a 2-dimentional view of product
backlog which highlights timelines and
dependencies.
Flight Plan!
Notes
25Copyright 2014 IQ Business
Notes
26 Copyright 2014 IQ Business
References
27Copyright 2014 IQ Business
1. Schwaber, K. & Sutherland, J. (2013, July). Scrum Guide. Retrieved from https://www.scrum.org/Scrum-Guide
2. Scrum Alliance. (2014). Agile Atlas. Retrieved from http://agileatlas.org/
3. Cohn, M. (n.d.). Retrieved from http://www.mountaingoatsoftware.com/agile/scrum
4. Greaves, K. & Laing, S. (2013). Growing Agile: A Coach’s Guide to Training Scrum. Lean Pub.
5. Greaves, K. & Laing, S. (2014). Impediments [Video]. Youtube.
6. De Gregorio, B. (2014). Agile Boot Camp. Using the Scrum Framework [Presentation].
7. Watts, G. (2013). Scrum Mastery: From Good To Great Servant-Leadership. Inspect & Adapt Ltd.
Further Reading
28
Title: Succeeding with Agile: Software Development
Using Scrum
Author(s): Mike Cohn
Publisher: Addison-Wesley
Publication Date: 2010
Title: Agile Estimating and Planning
Author(s): Mike Cohn
Publisher: Prentice Hall
Publication Date: June 2010
Title: Agile Product Management with Scrum
Author(s): Roman Pichler
Publisher: Addison Wesley
Publication Date: 2010
Title: Agile Retrospectives
Author(s): Esther Derby and Diana Larsen
Publisher: Pragmatic Programmers
Publication Date: 2006
Title: Agile Software Development with Scrum
Author(s): Ken Schwaber, Mike Beedle
Publisher: Prentice Hall
Publication Date: 2002
Title: Agile Testing: A Practical Guide for Testers and
Agile Teams
Author(s): Lisa Crispin and Janet Gregory
Publisher: Addison-Wesley
Publication Date: 2009
Title: Clean Code
Author(s): Martin
Publisher: Prentice Hall
Publication Date: 2009
Title: Continuous Integration
Author(s): Paul Duvall
Publisher: Addison Wesley
Publication Date: 2007
Title: Extreme Programming Explained
Author(s): Kent Beck
Publisher: Addison Wesley
Publication Date: 2007
Title: Extreme Programming Installed
Author(s): Jeffries, Anderson, and Hendrickson
Publisher: Addison-Wesley
Publication Date: 2001
Title: How Do We Know When We Are Done?
Author(s): Mitch Lacey
Publisher: Scrum Alliance Website Article
Publication Date: 2008
Title: Implementing Lean Software Development
Author(s): Mary Poppendieck, Tom Poppendieck
Publisher: Addison Wesley
Publication Date: July 2007
Title: Planning Extreme Programming
Author(s): Kent Beck, Martin Fowler
Publisher: Addison Wesley
Publication Date: December 2004
Title: Pragmatic Project Automation
Author(s): Clark
Publisher: Pragmatic Books
Publication Date: 2004
Title: Project Retrospectives: A Handbook for Team Re-
views
Author(s): Norman L. Kerth
Publisher: Dorset House Publishing
Publication Date: 2001
Title: Promiscuous Pairing and Beginner’s Mind: Em-
brace Inexperience
Author(s): Arlo Belshee
Publisher: IEEE
Publication Date: 2006
Title: Refactoring: Improving the Design of Existing
Code
Author(s): Fowler
Publisher: Addison-Wesley
Publication Date: 1999
Title: Retrospectives – The Missing Practice
Author(s): Tim Mackinnon
Publisher: ThoughtWorks Company
Publication Date: 2003
Title: Scrum Primer
Author(s): Pete Deemer, Gabrielle Benefield,
Craig Larman and Bas Vodde
Publisher:
Publication Date: 2010
Title: User Stories Applied
Author(s): Mike Cohn
Publisher: Addison Wesley
Publication Date: 2004
Copyright 2014 IQ Business
Practical Guide to Scrum
IQ Business Park
Third Avenue
Rivonia
Johannesburg
www.iqbusiness.co.za
agility@iqgroup.net
Follow up on Twitter
@AgilityIQ
Join our LinkedIn group
Agility@IQ

Contenu connexe

Tendances

Agile scrum fundamentals
Agile scrum fundamentalsAgile scrum fundamentals
Agile scrum fundamentalsDeniz Gungor
 
Scrum 101
Scrum 101Scrum 101
Scrum 101beLithe
 
Understanding Scrum
Understanding ScrumUnderstanding Scrum
Understanding ScrumClayDesk
 
Agile Scrum software methodology
Agile Scrum software methodologyAgile Scrum software methodology
Agile Scrum software methodologyAbdullah Raza
 
Introduction To Scrum
Introduction To ScrumIntroduction To Scrum
Introduction To ScrumDave Neuman
 
Agile Process Introduction
Agile Process IntroductionAgile Process Introduction
Agile Process IntroductionNguyen Hai
 
Scrum and the agile development process
Scrum and the agile development processScrum and the agile development process
Scrum and the agile development processjhericks
 
Introduction to Agile software testing
Introduction to Agile software testingIntroduction to Agile software testing
Introduction to Agile software testingKMS Technology
 
Scrum Training (One Day)
Scrum Training (One Day)Scrum Training (One Day)
Scrum Training (One Day)beLithe
 
Scrum 101: Introduction to Scrum
Scrum 101: Introduction to ScrumScrum 101: Introduction to Scrum
Scrum 101: Introduction to ScrumArrielle Mali
 
Introduction to SAFe, the Scaled Agile Framework
Introduction to SAFe, the Scaled Agile FrameworkIntroduction to SAFe, the Scaled Agile Framework
Introduction to SAFe, the Scaled Agile Frameworksrondal
 
Scrum Agile Methodlogy
Scrum Agile MethodlogyScrum Agile Methodlogy
Scrum Agile MethodlogyBahaa Farouk
 

Tendances (20)

Agile scrum fundamentals
Agile scrum fundamentalsAgile scrum fundamentals
Agile scrum fundamentals
 
Scrum in a nutshell
Scrum in a nutshellScrum in a nutshell
Scrum in a nutshell
 
Scrum 101
Scrum 101Scrum 101
Scrum 101
 
Scrum 101
Scrum 101 Scrum 101
Scrum 101
 
Agile (Scrum)
Agile (Scrum)Agile (Scrum)
Agile (Scrum)
 
Understanding Scrum
Understanding ScrumUnderstanding Scrum
Understanding Scrum
 
What Is Agile Scrum
What Is Agile ScrumWhat Is Agile Scrum
What Is Agile Scrum
 
Agile Scrum software methodology
Agile Scrum software methodologyAgile Scrum software methodology
Agile Scrum software methodology
 
Introduction To Scrum
Introduction To ScrumIntroduction To Scrum
Introduction To Scrum
 
Agile Process Introduction
Agile Process IntroductionAgile Process Introduction
Agile Process Introduction
 
Scrum
ScrumScrum
Scrum
 
Agile & Scrum Training
Agile & Scrum TrainingAgile & Scrum Training
Agile & Scrum Training
 
Scrum and the agile development process
Scrum and the agile development processScrum and the agile development process
Scrum and the agile development process
 
Introduction to Agile software testing
Introduction to Agile software testingIntroduction to Agile software testing
Introduction to Agile software testing
 
Scrum Training (One Day)
Scrum Training (One Day)Scrum Training (One Day)
Scrum Training (One Day)
 
Scrum 101: Introduction to Scrum
Scrum 101: Introduction to ScrumScrum 101: Introduction to Scrum
Scrum 101: Introduction to Scrum
 
Agile Introduction - Scrum Framework
Agile Introduction - Scrum FrameworkAgile Introduction - Scrum Framework
Agile Introduction - Scrum Framework
 
Introduction to SAFe, the Scaled Agile Framework
Introduction to SAFe, the Scaled Agile FrameworkIntroduction to SAFe, the Scaled Agile Framework
Introduction to SAFe, the Scaled Agile Framework
 
Scrum
ScrumScrum
Scrum
 
Scrum Agile Methodlogy
Scrum Agile MethodlogyScrum Agile Methodlogy
Scrum Agile Methodlogy
 

En vedette

How to build a superstar self-organizing team?
How to build a superstar self-organizing team?How to build a superstar self-organizing team?
How to build a superstar self-organizing team?Oleksandr Lutsaievskyi
 
Talent assessment and succession
Talent assessment and successionTalent assessment and succession
Talent assessment and successionJosh Dugan
 
Agile matrix organization design
Agile matrix organization designAgile matrix organization design
Agile matrix organization designFaustino Palma
 
Talent management January 2013
Talent management January 2013Talent management January 2013
Talent management January 2013Timothy Holden
 
Managing Matrix Organization
Managing Matrix OrganizationManaging Matrix Organization
Managing Matrix Organizationinformusa
 
The Paradox of Agile Architecture Quality: Designing for Failure
The Paradox of Agile Architecture Quality: Designing for FailureThe Paradox of Agile Architecture Quality: Designing for Failure
The Paradox of Agile Architecture Quality: Designing for FailureJason Bloomberg
 
Self-organization case study blinkist & zalando technology
Self-organization case study blinkist & zalando technologySelf-organization case study blinkist & zalando technology
Self-organization case study blinkist & zalando technologyTobias Leonhardt
 
New Industrial Revolution and Digital Business Models
New Industrial Revolution and Digital Business ModelsNew Industrial Revolution and Digital Business Models
New Industrial Revolution and Digital Business ModelsRobin Teigland
 
Career matrix jsif2 april2016
Career matrix jsif2 april2016Career matrix jsif2 april2016
Career matrix jsif2 april2016Leahcim Semaj
 
3 steps to implement holacracy in your company
3 steps to implement holacracy in your company3 steps to implement holacracy in your company
3 steps to implement holacracy in your companyKozo Takei
 
Value Creation Plane
Value Creation PlaneValue Creation Plane
Value Creation PlaneNeal Cabage
 
Search sur mobile : Quels enjeux ?
Search sur mobile : Quels enjeux ? Search sur mobile : Quels enjeux ?
Search sur mobile : Quels enjeux ? Thiga
 
Platform Revolution - Ch 02 Network Effects: Power of the Platform
Platform Revolution - Ch 02 Network Effects: Power of the PlatformPlatform Revolution - Ch 02 Network Effects: Power of the Platform
Platform Revolution - Ch 02 Network Effects: Power of the PlatformGeoff Parker
 
Business Model Archetypes
Business Model ArchetypesBusiness Model Archetypes
Business Model ArchetypesNeal Cabage
 
Full stackagile - Squads Chapters Tribes and Guilds
Full stackagile - Squads Chapters Tribes and GuildsFull stackagile - Squads Chapters Tribes and Guilds
Full stackagile - Squads Chapters Tribes and GuildsAshley-Christian Hardy
 

En vedette (20)

Effective user stories for your agile or Scrum team
Effective user stories for your agile or Scrum teamEffective user stories for your agile or Scrum team
Effective user stories for your agile or Scrum team
 
Defining tasks for User Stories
Defining tasks for User StoriesDefining tasks for User Stories
Defining tasks for User Stories
 
How to build a superstar self-organizing team?
How to build a superstar self-organizing team?How to build a superstar self-organizing team?
How to build a superstar self-organizing team?
 
Agile In An Hour
Agile In An HourAgile In An Hour
Agile In An Hour
 
Holacracy @ARCA
Holacracy @ARCAHolacracy @ARCA
Holacracy @ARCA
 
Talent assessment and succession
Talent assessment and successionTalent assessment and succession
Talent assessment and succession
 
Agile matrix organization design
Agile matrix organization designAgile matrix organization design
Agile matrix organization design
 
Talent management January 2013
Talent management January 2013Talent management January 2013
Talent management January 2013
 
Managing Matrix Organization
Managing Matrix OrganizationManaging Matrix Organization
Managing Matrix Organization
 
The Paradox of Agile Architecture Quality: Designing for Failure
The Paradox of Agile Architecture Quality: Designing for FailureThe Paradox of Agile Architecture Quality: Designing for Failure
The Paradox of Agile Architecture Quality: Designing for Failure
 
Self-organization case study blinkist & zalando technology
Self-organization case study blinkist & zalando technologySelf-organization case study blinkist & zalando technology
Self-organization case study blinkist & zalando technology
 
Career Matrix
Career MatrixCareer Matrix
Career Matrix
 
New Industrial Revolution and Digital Business Models
New Industrial Revolution and Digital Business ModelsNew Industrial Revolution and Digital Business Models
New Industrial Revolution and Digital Business Models
 
Career matrix jsif2 april2016
Career matrix jsif2 april2016Career matrix jsif2 april2016
Career matrix jsif2 april2016
 
3 steps to implement holacracy in your company
3 steps to implement holacracy in your company3 steps to implement holacracy in your company
3 steps to implement holacracy in your company
 
Value Creation Plane
Value Creation PlaneValue Creation Plane
Value Creation Plane
 
Search sur mobile : Quels enjeux ?
Search sur mobile : Quels enjeux ? Search sur mobile : Quels enjeux ?
Search sur mobile : Quels enjeux ?
 
Platform Revolution - Ch 02 Network Effects: Power of the Platform
Platform Revolution - Ch 02 Network Effects: Power of the PlatformPlatform Revolution - Ch 02 Network Effects: Power of the Platform
Platform Revolution - Ch 02 Network Effects: Power of the Platform
 
Business Model Archetypes
Business Model ArchetypesBusiness Model Archetypes
Business Model Archetypes
 
Full stackagile - Squads Chapters Tribes and Guilds
Full stackagile - Squads Chapters Tribes and GuildsFull stackagile - Squads Chapters Tribes and Guilds
Full stackagile - Squads Chapters Tribes and Guilds
 

Similaire à Practical Guide to Scrum

CampusSDN2017 - Jawdat: Product Management and Agile Development
CampusSDN2017 - Jawdat: Product Management and Agile DevelopmentCampusSDN2017 - Jawdat: Product Management and Agile Development
CampusSDN2017 - Jawdat: Product Management and Agile DevelopmentJawdatTI
 
User Story Prioritization Technique.pptx
User Story Prioritization Technique.pptxUser Story Prioritization Technique.pptx
User Story Prioritization Technique.pptxKnoldus Inc.
 
Keeping Product Backlog Healthy
Keeping Product Backlog HealthyKeeping Product Backlog Healthy
Keeping Product Backlog HealthyDhaval Panchal
 
The Whole Story of The User Story
The Whole Story of The User StoryThe Whole Story of The User Story
The Whole Story of The User StoryXPDays
 
ABC of Agile (Scrum & Extreme Programming)
ABC of Agile (Scrum & Extreme Programming)ABC of Agile (Scrum & Extreme Programming)
ABC of Agile (Scrum & Extreme Programming)Amardeep Vishwakarma
 
pspotrainingbymanoharprasad-230119074638-553afd9f.ppt
pspotrainingbymanoharprasad-230119074638-553afd9f.pptpspotrainingbymanoharprasad-230119074638-553afd9f.ppt
pspotrainingbymanoharprasad-230119074638-553afd9f.pptMouhamed Anouar Fersi
 
Tune Agile Test Strategies to Project and Product Maturity
Tune Agile Test Strategies to Project and Product MaturityTune Agile Test Strategies to Project and Product Maturity
Tune Agile Test Strategies to Project and Product MaturityTechWell
 
The Agile Readiness Assessment Tool Essay
The Agile Readiness Assessment Tool EssayThe Agile Readiness Assessment Tool Essay
The Agile Readiness Assessment Tool EssayHeidi Owens
 
Mark Foley Agile Methods And The Business Analystc
Mark Foley   Agile Methods And The Business AnalystcMark Foley   Agile Methods And The Business Analystc
Mark Foley Agile Methods And The Business AnalystcMia Horrigan
 
Product management class rookie to pro
Product management class rookie to proProduct management class rookie to pro
Product management class rookie to proBim Akinfenwa
 
Agile Software Development Model
Agile Software Development ModelAgile Software Development Model
Agile Software Development ModelRitika Balagan
 
How to Best Develop a Product by PlateRate Founder
How to Best Develop a Product by PlateRate FounderHow to Best Develop a Product by PlateRate Founder
How to Best Develop a Product by PlateRate FounderProduct School
 
Agile intro resources
Agile intro resourcesAgile intro resources
Agile intro resourcesAnwar Sadat
 
Introduction to Agile Scrum
Introduction to Agile ScrumIntroduction to Agile Scrum
Introduction to Agile ScrumHiep Luong
 

Similaire à Practical Guide to Scrum (20)

Scrum introduc.ppt
Scrum introduc.pptScrum introduc.ppt
Scrum introduc.ppt
 
CampusSDN2017 - Jawdat: Product Management and Agile Development
CampusSDN2017 - Jawdat: Product Management and Agile DevelopmentCampusSDN2017 - Jawdat: Product Management and Agile Development
CampusSDN2017 - Jawdat: Product Management and Agile Development
 
Scrum it up!
Scrum it up!Scrum it up!
Scrum it up!
 
User Story Prioritization Technique.pptx
User Story Prioritization Technique.pptxUser Story Prioritization Technique.pptx
User Story Prioritization Technique.pptx
 
Keeping Product Backlog Healthy
Keeping Product Backlog HealthyKeeping Product Backlog Healthy
Keeping Product Backlog Healthy
 
BAAgileQA
BAAgileQABAAgileQA
BAAgileQA
 
The Whole Story of The User Story
The Whole Story of The User StoryThe Whole Story of The User Story
The Whole Story of The User Story
 
ABC of Agile (Scrum & Extreme Programming)
ABC of Agile (Scrum & Extreme Programming)ABC of Agile (Scrum & Extreme Programming)
ABC of Agile (Scrum & Extreme Programming)
 
pspotrainingbymanoharprasad-230119074638-553afd9f.ppt
pspotrainingbymanoharprasad-230119074638-553afd9f.pptpspotrainingbymanoharprasad-230119074638-553afd9f.ppt
pspotrainingbymanoharprasad-230119074638-553afd9f.ppt
 
Agile scrum induction
Agile scrum inductionAgile scrum induction
Agile scrum induction
 
Tune Agile Test Strategies to Project and Product Maturity
Tune Agile Test Strategies to Project and Product MaturityTune Agile Test Strategies to Project and Product Maturity
Tune Agile Test Strategies to Project and Product Maturity
 
Scrum in One Day
Scrum in One DayScrum in One Day
Scrum in One Day
 
The Agile Readiness Assessment Tool Essay
The Agile Readiness Assessment Tool EssayThe Agile Readiness Assessment Tool Essay
The Agile Readiness Assessment Tool Essay
 
Mark Foley Agile Methods And The Business Analystc
Mark Foley   Agile Methods And The Business AnalystcMark Foley   Agile Methods And The Business Analystc
Mark Foley Agile Methods And The Business Analystc
 
Product management class rookie to pro
Product management class rookie to proProduct management class rookie to pro
Product management class rookie to pro
 
Agile Software Development Model
Agile Software Development ModelAgile Software Development Model
Agile Software Development Model
 
PSPO Training by Manohar Prasad.ppt
PSPO Training by Manohar Prasad.pptPSPO Training by Manohar Prasad.ppt
PSPO Training by Manohar Prasad.ppt
 
How to Best Develop a Product by PlateRate Founder
How to Best Develop a Product by PlateRate FounderHow to Best Develop a Product by PlateRate Founder
How to Best Develop a Product by PlateRate Founder
 
Agile intro resources
Agile intro resourcesAgile intro resources
Agile intro resources
 
Introduction to Agile Scrum
Introduction to Agile ScrumIntroduction to Agile Scrum
Introduction to Agile Scrum
 

Plus de Pavel Dabrytski

Основы психологии Agile коучинга
Основы психологии Agile коучингаОсновы психологии Agile коучинга
Основы психологии Agile коучингаPavel Dabrytski
 
How to Ace Your Scrum Master Interview
How to Ace Your Scrum Master InterviewHow to Ace Your Scrum Master Interview
How to Ace Your Scrum Master InterviewPavel Dabrytski
 
Scientific Method to Hire Great Scrum Masters
Scientific Method to Hire Great Scrum MastersScientific Method to Hire Great Scrum Masters
Scientific Method to Hire Great Scrum MastersPavel Dabrytski
 
Psychology of Agile Coaching [NEW]
Psychology of Agile Coaching [NEW]Psychology of Agile Coaching [NEW]
Psychology of Agile Coaching [NEW]Pavel Dabrytski
 
Psychology of Agile Coaching
Psychology of Agile CoachingPsychology of Agile Coaching
Psychology of Agile CoachingPavel Dabrytski
 
Extreme Personas – Innovate through User Experience
Extreme Personas – Innovate through User ExperienceExtreme Personas – Innovate through User Experience
Extreme Personas – Innovate through User ExperiencePavel Dabrytski
 
Building a Winning Business Through Business Model Canvas
Building a Winning Business Through Business Model CanvasBuilding a Winning Business Through Business Model Canvas
Building a Winning Business Through Business Model CanvasPavel Dabrytski
 
Agile Economics: Budgets, Contracts, Capitalization
Agile Economics: Budgets, Contracts, CapitalizationAgile Economics: Budgets, Contracts, Capitalization
Agile Economics: Budgets, Contracts, CapitalizationPavel Dabrytski
 
Requirements Engineering for Agile Product Owners
Requirements Engineering for Agile Product OwnersRequirements Engineering for Agile Product Owners
Requirements Engineering for Agile Product OwnersPavel Dabrytski
 
User-Centered Design with Pragmatic Personas
User-Centered Design with Pragmatic PersonasUser-Centered Design with Pragmatic Personas
User-Centered Design with Pragmatic PersonasPavel Dabrytski
 
Agile Economics: Budgets, Contacts, Capitalization [Flipchart]
Agile Economics: Budgets, Contacts, Capitalization [Flipchart]Agile Economics: Budgets, Contacts, Capitalization [Flipchart]
Agile Economics: Budgets, Contacts, Capitalization [Flipchart]Pavel Dabrytski
 
Kano Prioritasation Model
Kano Prioritasation ModelKano Prioritasation Model
Kano Prioritasation ModelPavel Dabrytski
 
10 Agile Anti-patterns in Distributed Teams
10 Agile Anti-patterns in Distributed Teams10 Agile Anti-patterns in Distributed Teams
10 Agile Anti-patterns in Distributed TeamsPavel Dabrytski
 
Agile for non-IT projects
Agile for non-IT projectsAgile for non-IT projects
Agile for non-IT projectsPavel Dabrytski
 

Plus de Pavel Dabrytski (17)

Основы психологии Agile коучинга
Основы психологии Agile коучингаОсновы психологии Agile коучинга
Основы психологии Agile коучинга
 
How to Ace Your Scrum Master Interview
How to Ace Your Scrum Master InterviewHow to Ace Your Scrum Master Interview
How to Ace Your Scrum Master Interview
 
Scientific Method to Hire Great Scrum Masters
Scientific Method to Hire Great Scrum MastersScientific Method to Hire Great Scrum Masters
Scientific Method to Hire Great Scrum Masters
 
Immunity to Change
Immunity to ChangeImmunity to Change
Immunity to Change
 
Psychology of Agile Coaching [NEW]
Psychology of Agile Coaching [NEW]Psychology of Agile Coaching [NEW]
Psychology of Agile Coaching [NEW]
 
Psychology of Agile Coaching
Psychology of Agile CoachingPsychology of Agile Coaching
Psychology of Agile Coaching
 
Extreme Personas – Innovate through User Experience
Extreme Personas – Innovate through User ExperienceExtreme Personas – Innovate through User Experience
Extreme Personas – Innovate through User Experience
 
Building a Winning Business Through Business Model Canvas
Building a Winning Business Through Business Model CanvasBuilding a Winning Business Through Business Model Canvas
Building a Winning Business Through Business Model Canvas
 
Agile Economics: Budgets, Contracts, Capitalization
Agile Economics: Budgets, Contracts, CapitalizationAgile Economics: Budgets, Contracts, Capitalization
Agile Economics: Budgets, Contracts, Capitalization
 
Requirements Engineering for Agile Product Owners
Requirements Engineering for Agile Product OwnersRequirements Engineering for Agile Product Owners
Requirements Engineering for Agile Product Owners
 
User-Centered Design with Pragmatic Personas
User-Centered Design with Pragmatic PersonasUser-Centered Design with Pragmatic Personas
User-Centered Design with Pragmatic Personas
 
Agile Economics: Budgets, Contacts, Capitalization [Flipchart]
Agile Economics: Budgets, Contacts, Capitalization [Flipchart]Agile Economics: Budgets, Contacts, Capitalization [Flipchart]
Agile Economics: Budgets, Contacts, Capitalization [Flipchart]
 
Kano Prioritasation Model
Kano Prioritasation ModelKano Prioritasation Model
Kano Prioritasation Model
 
Agile Personas
Agile PersonasAgile Personas
Agile Personas
 
10 Agile Anti-patterns in Distributed Teams
10 Agile Anti-patterns in Distributed Teams10 Agile Anti-patterns in Distributed Teams
10 Agile Anti-patterns in Distributed Teams
 
Agile for non-IT projects
Agile for non-IT projectsAgile for non-IT projects
Agile for non-IT projects
 
Lean vs scrum
Lean vs scrumLean vs scrum
Lean vs scrum
 

Dernier

Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.YounusS2
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDELiveplex
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesMd Hossain Ali
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...Aggregage
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UbiTrack UK
 
NIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopNIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopBachir Benyammi
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesDavid Newbury
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfinfogdgmi
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Websitedgelyza
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1DianaGray10
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxUdaiappa Ramachandran
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXTarek Kalaji
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfJamie (Taka) Wang
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemAsko Soukka
 

Dernier (20)

Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
 
NIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopNIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 Workshop
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond Ontologies
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdf
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Website
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptx
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBX
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystem
 

Practical Guide to Scrum

  • 1. Practical Guide to Scrum by Pavel Dabrytski
  • 2. COPYRIGHT AND CONFIDENTIALITY NOTIFICATION: The information contained in this document is proprietary information which is protected by copyright and at law. All rights are reserved. No part of the information contained in this document may be copied, reproduced, disseminated, transmitted, transcribed, extracted, stored in a retrieval system or translated in any form or by any means, without the prior written consent of IQ Business. The information contained herein is confidential to IQ Business. version 2.0. 7 April 2014. Huge thank you to Ayanda Mkize, Biase De Gregorio and Hannah Ward for reviewing the guide and leaving me hundreds of review notes!
  • 3. Agile 3 Agile Manifesto and ScrumValues are the heart of any agile implementation Individuals and interactions over Process and tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan Agile Manifesto Definition of Agility “Agility is the continued readiness “to rapidly or inherently create change, proactively or reactively embrace change, and learn from change while contributing to perceived customer value (economy, quality, and simplicity), through its collective components and r e l a t i o n s h i p s w i t h i t s environment.” Conby 2009. Keys to a successful Scrum team?  Roles of scrum master and product owner are performed by the right people  Scrum master and product owner have enough time to perform their duties  Development team is co-located  Members of the development team are dedicated to that team (100% allocated)  Development team is cross-functional  Development team is self-organised Agile principles 1. Early and continuous delivery of valuable software 2. Welcome changing requirements 3. Deliver working software frequently 4. Business people and developers must work together 5. Motivated individuals produce the best results 6. Face-to-face conversation is the most valuable 7. Progress is measured by working software 8. Enforce a sustainable development pace 9. Technical excellence enhances agility (and quality) 10. Simplicity 11. Self-organising teams produce the best solutions 12. At regular intervals, the team adjusts its behavior to become more effective Copyright 2014 IQ Business
  • 4. Scrum Framework 4 This picture represent the full Scrum process Copyright 2014 IQ Business
  • 5. Product Vision 5 Product vision is a short statement which describes end goals, objectives and benefits of the product Who owns vision? Moore’s product vision model FOR: «target customer» WHO: «needs» THE: «product name» IS A: «product category» THAT: «product benefit. Reason to buy» UNLIKE: «competitors» OUR PRODUCT: «differentiation or value proposition». Product owner. However everyone contributes towards the product vision. Example FOR a mid-sized company's marketing and sales departments WHO need basic CRM functionality, THE CRM-Innovator IS A web-based service THAT provides sales tracking, lead generation, and sales representative support features that improve customer relationships at critical touch points. UNLIKE other services or package software products, OUR PRODUCT provides very capable services at a moderate cost. ? Absolutely! Product vision should reflect current business conditions (market, budget, capacity etc.). However, constantly changing vision is an indication of a problem. Product owner together with stakeholders and the team. Can vision be updated?? Who updates vision?? Elevator test “Can you explain your product in the time it takes to ride up in an elevator?” Moore (2006, p. 152). Passing this test ensures that your product vision is clear, engaging, and brief. !WHEN WHY First thing. Before product Backlog. Product vision is needed to ensure the product is moving in the right direction, strategies are aligned and that the development team spends its time creating the right product. Copyright 2014 IQ Business
  • 6. Product Backlog 6 Product backlog is a single list of features/requirements for the product, prioritised by value Product backlog  Contains features, defects, technical work, knowledge acquisition  Ordered by priority  Prioritised by product owner with help from the development team and stakeholders  Physical wall, white board, index cards and post-it notes (recommended)  Excel (most widely used)  Any other electronic tools such as TFS, VersionOne, Pivotal Tracker, etc. MoSCoW prioritization Must have—all “must have” stories form the minimal viable product (MVP) and good enough for the first release Should have—all “should have” stories make this product competitive Could Have—all “could have” stories delight the customer Won’t Have—All “won’t have” stories aren’t worth doing. The majority of stories (65%) should fall into the “won’t have” pile Tools for product backlog! If team works on multiple projects or products at the same time, we suggest creating a single team backlog. The product owner must prioritize work for multiple projects within this backlog. It will help the team to keep focused and will save time on scrum meetings. Multiple projects? MoSCow is only one of many. You may look at Kano, Buy-a-feature, The Product tree and others. Prioritization techniques! Backlog iceberg Backlog Iceberg is an Agile just-in-time technique. User stories in Product Backlog are stored in different levels of detail where highest priority (top of the iceberg) stories are most detailed. Copyright 2014 IQ Business
  • 7. User Story & Acceptance Criteria 7 User story is an agile technique to facilitate requirement management Acceptance criteria—checklist which defines acceptance testing for this particular story Wrong story format ‘As a BA I will document price history’  This user story is missing the actual user role. It is impossible to identify the person or role who will benefit from the user story  This user story doesn’t explain the reason why completing it is valuable and beneficial. ! Story Formats [Beginner] - Simple statement of functionality which needs to be build. example: ‘View email history.’ [Classic] - Connextra format: As a <user role>, I want <goal/desire> so that <benefit>. example: ‘As a senior support agent I want to view the emails send to the customer, so I know which communication took place.’ [Advanced] - In order to <receive benefit> as a <user role> I want <goal/desire>. example: ‘In order to be able to assist customer promptly, as a senior support agent I want to view previous customer email communication on my agent dashboard.’ Acceptance Criteria Format [Beginner] - Simple description on how functionality should work. example: ‘Only show last 2 emails sent to the customer’ ‘When pressing “resend email”, show example of email sent’ [Advanced] - Given <precondition> When <scenario> Then <expected result>. example: ‘Given that customer didn’t receive any emails yet, when agent opens dashboard, then ‘no previous emails’ message is displayed.’ Definition of Done vs Acceptance criteria Definition of done is generic and applicable to all stories. Acceptance criteria is specific and is different for different user stories. ! Copyright 2014 IQ Business
  • 8. Definition of Done 8 Definition of done is a checklist of valuable activities required to produce complete software Definition of done is unique per team, although it might contain some elements which are required by the department, organisation or industry. Example  All development has been completed  Functionality has been tested by developer  Unit tests have been completed  New business functionality satisfies acceptance criteria in TFS*  All features have been tested in IE8** and IE9**  Regression tested in IE8** & IE9** test environment  Code has been reviewed by another developer  Story has been reviewed by product owner, and product owner has accepted all open issues, if any DoD per team! Definition of done may change over time as the team continues to build the product and learn from the process. Usually definition of done is reviewed by the whole team at one of the sprint events (i.e. sprint retrospective or sprint planning). Can DoD change?? Definition of done vs acceptance criteria Definition of done is generic and applicable to all stories. Acceptance criteria is specific and is different for different user stories. ! *- Team Foundation Server ** - Internet Explorer Copyright 2014 IQ Business
  • 9. Relative Estimation 9 Planning poker Planning poker is a consensus-based technique for estimation. It helps avoiding the influence of the other participants. Here is the procedure:  User story is selected  Product owner (or scrum master) briefly explains the story and answers any related questions (2mins)  Voting occurs (1st round)  If the estimates show a large variation, a further 2 mins should be used to explain why the estimates should be higher or lower  Voting occurs (2nd round)  If the estimates still show a large variation, a further 2 mins should be used to re-explain/justify the estimates  Voting occurs (3rd round)  If, after the 3rd round of voting, no consensus can be reached regarding the size, the story is placed on hold What NOT to do  Don’t allow anyone to shout estimation aloud before the team estimates together  Don’t allow anyone in the team or any stakeholder to override teams decisions (i.e. ‘come on guys, it is not 40, it is a 3’)  Don’t take an average of estimates without having discussions  Don’t allow people not to vote. Asking everyone to vote will improve the team’s understanding of each other’s work  Don’t assign story points by yourself. It is always a team discussion !  Estimation in relative points has proven to be quicker  It removes link between estimating effort and committing to timelines  It helps to remove false accuracy around estimates Why relative estimation?? Relative estimation is a forecasting technique with a story point as a unit of measure Modified Fibonacci Scale is 1 2 3 5 8 13 20 40 100 Estimation in relative points has proven to be quicker. Also estimation in hours is prone to further inaccuracies because it is based on ideal hours. Time vs points! A story point cannot be directly converted into hours. It only shows how much smaller or bigger the item is compared to other items in the backlog. It can be calculated of course, but such information should be used for release planning only (i.e. velocity), and not per story or task . How much is 1 point?? Velocities and estimates of different teams are not directly comparable due to different baselines/team norms. Comparing teams! Baseline When estimating for the first time, se- lect the smallest story and assign it 3 points. It will become your baseline. Copyright 2014 IQ Business
  • 10. Sprint 10 Sprint is a time-boxed event with a goal of producing working product at the end of it By order of popularity:  2 weeks  3 weeks  1 week  4 weeks Sprints should not be longer than 1 month. Popular sprint length!DOs  Consistent duration throughout life cycle of the project  New sprint starts immediately after the conclusion of the previous sprint  Schedule recurring meetings for all scrum events in team diaries  Create sprint goals for each sprint DONTs  Extend/shorten sprint after it commences  Have a couple of days gap between sprints  Add changes/stories which might endanger sprint goal  Decrease quality of work in order to finish stories in the sprint  Split testing and other quality checks into another sprint  Start a new sprint on Monday as it will end on Friday. People are not focused enough on Fridays  Don’t create “mini-waterfalls” during your sprints. In other words 1 sprint of analysis, 1 sprint of development and 1 sprint of testing Cancelling sprint  Only product owner can cancel a sprint  All events (sprint review, sprint retrospective & sprint planning) should take place in order to commence new sprint  There should be no gap between cancelled and new sprints  Try to avoid sprint cancellation  Daily scrum (standup)  Sprint planning  Backlog refinement (grooming)  Sprint review  Sprint retrospective Scrum events! Often sprints are called iterations. Iteration and sprint are the same concept. Iteration vs sprint! Copyright 2014 IQ Business
  • 11. Sprint Goal 11 Examples of sprint goal  In this sprint we will allow users to log-in to the site, retrieve a forgotten password, and manage their own profile  In this sprint we will implement basic shopping cart functionality including add, remove and update features  In this sprint we will integrate VISA payment gateway into our billing module and investigate MasterCard gateway ! Sprint Goal is a short (1-2 sentences) description of what the team plans to achieve during sprint  Whole team decides on sprint goal together with product owner, scrum master and stakeholders  Sprint goal must be realistic and SMART (specific, measurable, achievable, relevant and timely)  Sprint goal must not be forced onto the team  Sprint goal is decided during sprint planning event Copyright 2014 IQ Business
  • 12. Sprint Backlog 12 List of user stories, tasks and other activities team commits to deliver in order to achieve sprint goal  Use different colours for different types of tasks (i.e. development—blue, impediments—purple, business analysis—pink), but each team can define their own standards at visualizing sprint backlog  Limit number of user stories in progress—it will reduce amount of user stories carried over into next sprints  Limit number of impediments in progress—focus on most serious blockers first  Agree on maximum period of tome to resolve an impediment, before it is escalated to broader audience  Use index cards for user stories and post-it notes for tasks  A good user story can be done within 3 days and a good task should take no more than 1 day  Add your retrospective actions to sprint backlog as well  Use ‘Super Sticky’ post-it notes Tips! Copyright 2014 IQ Business
  • 13. Impediments 13 Problems with impediments  If the impediment backlog lives in the mysterious black book of the scrum master, you have a problem  If your impediment backlog does not change you have a problem  If your impediment backlog is empty, you have a problem  If you have an impediment backlog with a growing number of active impediments, you have a problem  If the scrum master resolves all impediments himself/ herself, you have a problem ! Impediment is anything which is standing in team’s way towards achieving the print goal Tips for dealing with impediments  Make the impediments visible—use special colour post-it notes for them  Search for impediments. Look out for impediment words (‘still waiting’, ‘not available’, ‘hopefully’, ‘wish’, ‘guess’, expected’, I thought’, ‘try’)  Limit the number of impediments. Select 3 biggest ones and put a big red dot on each of them. It will help the team focus  Help the team to resolve impediments ! 4th standup question One of the techniques to identify more impediments is to ask a 4th question at standup. ‘How confident are you that you will achieve sprint goal?’. If it is anything less than 100%, by asking why, you will discover an impediment. ‘How can we go faster?’ Is another question to bring out impediments to the surface. ? Global vs local impediments Global impediments need attention of your stakeholders and relevant stakeholders should be made aware of them as soon as possible. Local impediments are within team’s capability to resolve. ! Copyright 2014 IQ Business
  • 14. Sprint Burndown/Burnup 14 Sprint burndown/burnup are charts which represent progress of work during the sprint  Have user stories  Estimate each user story together with your team in story points (1 2 3 5 8 13 20 40 100)  Calculate total number of story points in sprint  Calculate total number of working days in sprint  Should be updated by the team at the same time every day What do you need to create one?? Points are reflected in the chart once a whole story is complete as per definition of done. In other words, if a story is not complete, it is calculated as 0. No points are assigned to tasks as an individual task doesn’t usually carry business value on its own. Story points! Both charts represent the same information. Burndown displays work outstanding Burnup displays work done Copyright 2014 IQ Business
  • 15. Daily Scrum [Standup] 15 Daily Scrum is an event to synchronise the team and plan for the next 24hrs What else to do at standup/after standup  Review impediments  Update burndown/burnup chart  Make decisions  Update sprint backlog (i.e. move post-it notes, add more tasks) !3 Standup Questions Each team member should answer these 3 questions:  What did I do yesterday that helped the development team meet the sprint goal?  What will I do today to help the development team to meet the sprint goal?  Are there any impediments that prevent me or the development team from meeting the sprint goal? WHEN WHY Every day Synchronise activities and create a plan for the next 24 hours HOW LONG 15 minutes WHO Mandatory: development team Optional: scrum master, product owner, stakeholders If you feel that a conversation is going on for too long and other team members start to lose interest, you can add the issue to the parking lot and ask those involved to discuss it right after the standup. Meet after? Copyright 2014 IQ Business
  • 16. Sprint Planning 16 Sprint Planning is an event to plan work for the sprint Typical agenda PART ONE: WHAT 1. Discuss team capacity 2. Identify sprint goal 3. Identify user stories needed to achieve sprint goal 4. Clarify requirements for these user stories 5. Update product backlog: split, delete, combine, move stories 6. Estimate user stories 7. Commit to sprint goal and user stories PART TWO: HOW 1. Decide how to achieve the sprint goal (design) 2. Clarify requirements further 3. Negotiate trade-offs 4. Break down stories into tasks 5. Update Scrum board First day of each sprint Plan work; obtain commitment for the sprint; eliminate other meetings; manage stakeholder expectations; mitigate risks 2 hours for every week of sprint Mandatory: development team, scrum master, product owner Optional: stakeholders Product owner should come to sprint planning prepared to talk about 2 sprints worth of work. Product owner?  Product backlog and its complexity  Stationery (post-it notes, index cards, markers)  Team capacity (how much time will team have to do the work): leave, public holidays, training etc.  Business conditions Prerequisites Copyright 2014 IQ Business WHEN WHY HOW LONG WHO
  • 17. Sprint Review 17 Sprint Review is an event for the team to show what they accomplished during the print and reflect on current state of the product Last day of each sprint before sprint retrospective Demonstrate results of sprint; discuss product and adjust product backlog; collaborate on the next goals; review timeline, budget, release plan 1 hour for every week of sprint Mandatory: development team, scrum master, product own- er, stakeholders  Say NO to slides, show working software instead  Say NO to showing incomplete stories  Say NO to scrum master or product owner doing demo, it is better for development team to demo their own work Say NO to...!  List of complete/incomplete stories  Big boardroom with projector screen  Laptop  Team needs to prepare for this event (~ 1 hour) Prerequisites Typical agenda  Review meeting agenda and guidelines  Team walkthrough of completed functionality with product owner  Team demonstrates working software to stakeholders  Team discusses incomplete user stories  Product owner moves/splits/re-prioritizes the backlog  Product owner closes the sprint and accepts relevant functionality (if it wasn’t accepted during the sprint)  Open actions/impediments are noted Copyright 2014 IQ Business WHEN WHY HOW LONG WHO
  • 18. Sprint Retrospective 18 Sprint retrospective is an event for the team to reflect on current progress and find improvements Typical agenda 5 stages of retrospective 1. Set the stage 2. Gather & analyze data 3. Generate insights 4. Decide what to do 5. Close the retrospective Practical example: 1. Each team member around the table says 3 words about previous sprint 2. Ask everyone to write 3 post-it notes for ‘what went well’ and ‘what can be improved’ and stick them on the wall 3. Group them into themes 4. Identify the most painful item 5. Brainstorm actions that can be taken in the next sprint to improve the item 6. Thumb vote on how retrospective went Last day of each sprint after sprint review Reflect on current progress; identify improvements 1-1.5 hours Mandatory: development team, scrum master Optional: retrospective should be safe place for the team to be truly open. Beware of inviting anyone outside of the development team as it might change dynamics of the retrospective. You can pick up more ideas for your sprint retrospective at http://plans-for-retrospectives.com/ Or invite other scrum masters to facilitate a session for you. More ideas!  White board  Post-it notes Prerequisites Make your actions SMART (specific, measurable, achievable, relevant and timely). Assign owners to retrospective actions. Put all retrospective actions on Scrum board (sprint backlog) and track them as any other work. Actions! Copyright 2014 IQ Business WHEN WHY HOW LONG WHO
  • 19. Backlog Refinement 19 Backlog refinement is an event to help the team to get user stories ready for future sprints During sprint, perhaps weekly Get user stories ready; add detail to user stories; estimate user stories; identify risks and issues before sprint planning; update priority of user stories 30 minutes—2 hours Mandatory: development team, scrum master, product owner Optional: stakeholders A good user story is: Independent / immediately actionable—ideally can be implemented in any order Negotiable—and negotiated Valuable—to the customer Estimatable—enough to rank and schedule it Small—and with short descriptions Testable—I could write a test for it INVEST!  Product backlog Prerequisites Typical Agenda 1. Identify user stories to refine 2. Clarify requirements for these user stories 3. Identify open items/questions for these user stories and assign owners to them 4. Break down user stories which are too big 5. Discuss priority of these user stories and update if necessary 6. Estimate user stories Copyright 2014 IQ Business WHEN WHY HOW LONG WHO
  • 20. 20 Scrum Roles  Cross functional  Dedicated (allocated 100% to the team)  Co-located  Self-organized  Ideal size for development team is 3 to 9 Development Team3 Roles in Scrum  Scrum Master  Product Owner  Development Team If person works daily together with development team towards achieving sprint goal, then he/she forms part of the team. Stakeholder or team member?
  • 21. 21Copyright 2014 IQ Business Scrum Master  Facilitate Scrum events  Identify and help to resolve impediments  Be guardian of Scrum process 3 Main responsibilities  Help the team to resolve impediments  Facilitate Scrum events (prepare, lead, writeup)  Help team to continuously improve their process  Maintain Scrum tools (story board, backlogs, charts, etc.)  Help team to create/maintain definition of done  Help to create/refine user stories  Coach team members, consult team members regarding everything agile  Resolve conflicts within the team  Help team to make decisions  Encourage team self-organisation  Mediate communication between development team and product owner  Continue personal growth in Agile (user groups, conferences, reading books and articles, writing blogs)  Interact constantly with other scrum masters within the organisation  Help with release planning  Be familiar with team's work/progress, feedback to stakeholders on team's progress  Bring right people together for communication  Keep in touch with stakeholders regularly  Give learning opportunities to people within the organisation  Arrange/capture team policies and agreements, remind the team about them  Ask open questions, encourage team members to express their opinions  Help the team to keep focus Full list of responsibilities Can product owner and scrum master be the same person? No. The roles have different goals and responsibilities. Product owner protects interests of stakeholders and scrum master protects interests of their development team. Often they play offense- defense, which is not possible to achieve when one person combines both roles. Scrum master vs product owner? Good scrum master can work with 2-3 teams at the same time, great scrum master always works with a single team. Multiple teams!
  • 22. 22 Copyright 2014 IQ Business Product Owner  Own product backlog  Prioritise work  Accept/reject work 3 Main responsibilities  Ensure that the team builds the right product  Manage ROI and make sure to deliver business benefits  Responsible for the budget constraints to be met  Ensure that what the team is asked to build is aligned with what the sponsor, stakeholders and users want  Provide a vision for the product  Provide boundaries to describe the realities within which the vision must be realised (e.g. time frames, external quality)  Make sure management, stakeholders, sponsors are informed and the vision is aligned with their wishes  Communicate the project vision to the team and motivate the team to subscribe to the product vision  Manage stakeholder expectations regarding requirements and project boundaries (time frames, quality, technical constraints etc.)  Create and maintain the product backlog (the product owner can delegate some of the work of writing user stories to a BA but the Product Owner is still responsible for ensuring that the work is being done and is being done properly)  Continuously refine the product backlog  Prioritise user stories within the product backlog  Define releases, their goals and sprint goals  Continuously answer questions to add detail to requirements/user stories  Accept/reject developed user stories at the end of the sprint (or during the sprint)  Communicate about the project within the organisation (e.g. demo attendance and invites, forecasting, management reporting, sponsor liaison) Full list of responsibilities Product owner is a full time role in many organisations. We suggest to spend at least 20 hours per week for each team in order to be able to achieve desirable outcomes. How much time do I need? Backlog owner or proxy product owner is usually an interim role during Agile implementation. Person in this role takes over product backlog management responsibilities. In mature teams this roles considered an anti-pattern as proxy product owner becomes a middle man in communication between product owner and the team. Proxy Product Owner!
  • 23. 23Copyright 2014 IQ Business Product Burnup Product burnup is a chart which represents the progress towards completing the product backlog  Have all requirements included in product backlog ( initially these requirements will be epics/high level features. With time, product owner and team will refine these epics into more detailed stories)  All stories and epics are estimated in story points What do you need to create one??  Project delivery date, based on historical velocity  Average velocity required to finish work by specific date  Is project ahead of behind schedule (comparing ideal and actual burning rates)?  Amount of carry over stories in each sprint and its trend  Velocity per sprint and its trend Valuable information!
  • 24. 24 Copyright 2014 IQ Business Release Plan Release plan shows days of release and epics/high level features to be realized in this specific release. Date Sprints Status Description Release 1 28/01/2014 2-3 Delivered Feature A Feature B Integration with system X Feature C Patch release 1.2 05/02/2014 4 Delivered Fixes for Feature C Patch release 1.3 09/02/2014 5 Delivered Fixes for Feature C and A Release 2 28/04/2014 6-8 Off track Feature D Migration of data Y Release 3 15/05/2014 9-10 Feature E Release as often as possible. It will allow for early feedback from users and stakeholders. First release should be your minimum viable product (MVP). How often to release? Flight Plan (Story Mapping, Critical Path) is a 2-dimentional view of product backlog which highlights timelines and dependencies. Flight Plan!
  • 26. Notes 26 Copyright 2014 IQ Business
  • 27. References 27Copyright 2014 IQ Business 1. Schwaber, K. & Sutherland, J. (2013, July). Scrum Guide. Retrieved from https://www.scrum.org/Scrum-Guide 2. Scrum Alliance. (2014). Agile Atlas. Retrieved from http://agileatlas.org/ 3. Cohn, M. (n.d.). Retrieved from http://www.mountaingoatsoftware.com/agile/scrum 4. Greaves, K. & Laing, S. (2013). Growing Agile: A Coach’s Guide to Training Scrum. Lean Pub. 5. Greaves, K. & Laing, S. (2014). Impediments [Video]. Youtube. 6. De Gregorio, B. (2014). Agile Boot Camp. Using the Scrum Framework [Presentation]. 7. Watts, G. (2013). Scrum Mastery: From Good To Great Servant-Leadership. Inspect & Adapt Ltd.
  • 28. Further Reading 28 Title: Succeeding with Agile: Software Development Using Scrum Author(s): Mike Cohn Publisher: Addison-Wesley Publication Date: 2010 Title: Agile Estimating and Planning Author(s): Mike Cohn Publisher: Prentice Hall Publication Date: June 2010 Title: Agile Product Management with Scrum Author(s): Roman Pichler Publisher: Addison Wesley Publication Date: 2010 Title: Agile Retrospectives Author(s): Esther Derby and Diana Larsen Publisher: Pragmatic Programmers Publication Date: 2006 Title: Agile Software Development with Scrum Author(s): Ken Schwaber, Mike Beedle Publisher: Prentice Hall Publication Date: 2002 Title: Agile Testing: A Practical Guide for Testers and Agile Teams Author(s): Lisa Crispin and Janet Gregory Publisher: Addison-Wesley Publication Date: 2009 Title: Clean Code Author(s): Martin Publisher: Prentice Hall Publication Date: 2009 Title: Continuous Integration Author(s): Paul Duvall Publisher: Addison Wesley Publication Date: 2007 Title: Extreme Programming Explained Author(s): Kent Beck Publisher: Addison Wesley Publication Date: 2007 Title: Extreme Programming Installed Author(s): Jeffries, Anderson, and Hendrickson Publisher: Addison-Wesley Publication Date: 2001 Title: How Do We Know When We Are Done? Author(s): Mitch Lacey Publisher: Scrum Alliance Website Article Publication Date: 2008 Title: Implementing Lean Software Development Author(s): Mary Poppendieck, Tom Poppendieck Publisher: Addison Wesley Publication Date: July 2007 Title: Planning Extreme Programming Author(s): Kent Beck, Martin Fowler Publisher: Addison Wesley Publication Date: December 2004 Title: Pragmatic Project Automation Author(s): Clark Publisher: Pragmatic Books Publication Date: 2004 Title: Project Retrospectives: A Handbook for Team Re- views Author(s): Norman L. Kerth Publisher: Dorset House Publishing Publication Date: 2001 Title: Promiscuous Pairing and Beginner’s Mind: Em- brace Inexperience Author(s): Arlo Belshee Publisher: IEEE Publication Date: 2006 Title: Refactoring: Improving the Design of Existing Code Author(s): Fowler Publisher: Addison-Wesley Publication Date: 1999 Title: Retrospectives – The Missing Practice Author(s): Tim Mackinnon Publisher: ThoughtWorks Company Publication Date: 2003 Title: Scrum Primer Author(s): Pete Deemer, Gabrielle Benefield, Craig Larman and Bas Vodde Publisher: Publication Date: 2010 Title: User Stories Applied Author(s): Mike Cohn Publisher: Addison Wesley Publication Date: 2004 Copyright 2014 IQ Business
  • 30. IQ Business Park Third Avenue Rivonia Johannesburg www.iqbusiness.co.za agility@iqgroup.net Follow up on Twitter @AgilityIQ Join our LinkedIn group Agility@IQ