View
5
Download
0
Category
Preview:
Citation preview
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
MTAT.03.243
Software Engineering Management
Lecture 06:
Agile Principles and
Processes – Part B
Dietmar Pfahl email: dietmar.pfahl@ut.ee
Spring 2015
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Structure of Lecture 06
• Scrum
• Choosing the right process (model)
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
The Term “Scrum”
• Originates from Rugby
• Meaning “crowded”
• Complex move that
requires team work
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
What is Scrum?
• Agile Management Framework for SW development projects
• With a few clear rules:
• Roles: Product Owner, Team, Scrum Master
• Product Backlog, Sprint Backlog, few compact reports
• Short work cycles (-> ”Sprints”) for incremental development
• Based on the Agile Manifesto of Kent Beck at al.
• Human-centred
• Technology and tools have secondary role
• Close cooperation with customer
• Empirical learning process
Scrum does not define a development methodology, QA strategy, or risk management approach, but asks the team to take care of these issues appropriately.
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Scrum Elements – Overview
http://www.scrumforteamsystem.com/processguidance/v1/Scrum/Scrum.html
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Scrum Process – Simplified Overview
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Typical
Scrum
Project
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
'Slice' of a Typical Scrum Project
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Initial Product Backlog
• Product Owner
– fills the initial product backlog with the product properties from the product
concept and other requirements from focus groups, interviews, user
observation, etc.
– Coarse-grained!
– Goal: All known functional and non-functional requirements should briefly
be described
• Product Owner
– groups similar requirements into themes
– prioritizes themes and individual requirements (if necessary) according to
usefulness, risk, and cost
• Further refinement of high-priority requirements via requirements workshops
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Requirements Workshop (Backlog Refinement Meeting)
• Joint workshop with product owner, team, end users, and all other relevant
stakeholders (e.g., marketing, sales) – duration: approx. 2 hours
• Goal: Common understanding of requirements
• Fills and refines the Product Backlog
• New themes / requirements are first described only at the level of coarse-grained
stories (so-called epics)
• Existing high-priority themes / requirements are detailed (-> proper User Stories) and
acceptance criteria are defined
• Often using index cards on Meta Planning Boards
• Team estimates the cost/size/complexity of requirements
– E.g. using points on a Fibonacci series (0, 1, 2, 3, 5, 8, 13, ...)
– Done as part of an estimation workshop, perhaps using “planning poker”
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Product Backlog
• A list of all desired work on the
project (-> the requirements)
• Ideally expressed such that each
item has value to the users or
customers of the product
• Prioritized by the product owner
• Reprioritized at the start of each
sprint
• Coarse-grained at the beginning of
the project, continuously refined in
requirements workshops
• Evolves over time!
This is the product backlog
Product Backlog
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Product Backlog (cont'd)
• Requirements (User Stories) are usually represented on index
cards or in a table, e.g.:
Independent Negotiable Valuable Estimable Small Testable
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Estimation Workshop (Backlog Refinement Meeting)
• Product Owner explains requirements to the team
• Team estimates effort (no other persons outside the team)
– Starting with small requirements and incrementally adding larger
ones (relative to the smaller ones)
– The estimates are only stable within a team; it is not possible to
transfer these estimates to other teams without further
considerations!
– All activities are taken into account (development, test, integration,
documentation, ...)
– Single estimates are done using, e.g., planning poker
• If requirements are too vague to estimate, they have to be
clarified first (e.g., making use of a so-called exploration Sprint)
• If a requirement is estimated as being “huge” (e.g., much larger
than all others), there may be a lack of understanding
• The Scrum Master moderates the estimation workshop
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Scrum Training Series
• Six Free Videos
• Available on Course Wiki
• With quizzes
http://scrumtrainingseries.com/ 1. Introduction to Scrum 2. Backlog Refinement Meeting 3. Sprint Planning Meeting 4. Daily Scrum Meeting 5. Sprint Review Meeting 6. Sprint Retrospective Meeting
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
How many Product Backlog
Items (PBIs) will typically be
developed in a Sprint?
• Take SI example (Homework 1 article)
• Assume one-month sprints
– ~4 weeks, i.e., 3 sprints per quarter
• Assume 6 person teams
---------------------------------------------------------
• Work in pairs
• You have 5 minutes ...
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
How many Product Backlog
Items (PBIs) will typically be
developed in a Sprint?
• Take SI example (Homework 1 article)
• Assume one-month sprints
– ~4 weeks, i.e., 3 sprints per quarter
• Assume 6 person teams
---------------------------------------------------------
Answer:
3 PBIs 5 PBIs
8 PBIs 12 PBIs
18 PBIs >18 PBIs
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
How many Product Backlog
Items (PBIs) will typically be
developed in a Sprint?
• Take SI example (Homework 1 article)
• Assume one-month sprints
– ~4 weeks, i.e., 3 sprints per quarter
• Assume 6 person teams
---------------------------------------------------------
Answer:
3 PBIs 5 PBIs
8 PBIs 12 PBIs
18 PBIs >18 PBIs
Figure 4(b) – p. 51
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
How many Product Backlog
Items (PBIs) will typically be
developed in a Sprint?
• Take SI example (Homework 1 article)
• Assume one-month sprints
– ~4 weeks, i.e., 3 sprints per quarter
• Assume 6 person teams
---------------------------------------------------------
Answer:
3 PBIs 5 PBIs
8 PBIs 12 PBIs
18 PBIs >18 PBIs
Figure 4(b) – p. 51 Text: Production: 190 PBIs per quarter Personnel: 34 persons -> 5.9 PBIs per person per quarter -> ~2 PBIs per person per month -> ~12 PBIs per 6 person-months
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
How many Tasks will
typically be developed in
a Sprint?
• Take SI example (Homework 1 article)
• Assume one-month sprints
– ~4 weeks, i.e., 3 sprints per quarter
• Assume 6 person teams
• Assume that one task should be implemented by one person
within 1 to 2 calendar days (40-hour week / 8-hour day)
------------------------------------------------------------------------------------
Answer:
40-80 tasks 60-120 tasks
90-180 tasks 120-240 tasks
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
How many Tasks will
typically be developed in
a Sprint?
• Take SI example (Homework 1 article)
• Assume one-month sprints
– ~4 weeks, i.e., 3 sprints per quarter
• Assume 6 person teams
• Assume that one task should be implemented by one person
within 1 to 2 calendar days (40-hour week / 8-hour day)
------------------------------------------------------------------------------------
Answer:
40-80 tasks 60-120 tasks
90-180 tasks 120-240 tasks
Calculation: 6 x 20/1 = 120 tasks 6 x 20/2 = 60 tasks
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Sprint – Overview
• Fixed period during which all activities specified in the Sprint Backlog are
carried out
• Max Sprint length: 30 days, but can also be shorter
• No extension possible (time-boxing approach) – if not all activities can be
completed by the end of the Sprint, they fall back into the Product Backlog
• Sprint is preceded by Sprint Planning and succeeded by Sprint Review and
Sprint Retrospective meetings
• Sprints follow each other seamlessly Backlog Refinement & Estimation Meeting
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Daily Scrum
Sp
rint R
eview
Meetin
g
Sp
rint R
etrosp
ective
Sp
rint P
lannin
g M
eeting
Sp
rint P
lannin
g M
eeting
15 min daily
~1 hour
1 day for a
4 week Sprint
Sprint Meetings
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Sprint planning meeting
Sprint prioritization
• Analyze and evaluate product
backlog (PBIs)
• Select sprint goal / commit PBIs
Sprint planning
• Decide how to achieve sprint goal
(design)
• Create sprint backlog (tasks) from
product backlog items (user stories /
features)
• Estimate sprint backlog in person-
hours
Sprint
goal
Sprint
backlog
Business
conditions
Team capacity
Product
backlog
Technology
Current
product
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Sprint Backlog
• Created during the Sprint Planning Meeting
• Updated at least at the end of every day
• Includes all activities (tasks) that have to be carried out in the Sprint
• Allows the team to organize all activities
• Usually documented as index cards on a Meta Planning Board
Sprint Goal
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Sprint Backlog
• Created during the Sprint Planning Meeting
• Updated at least at the end of every day
• Includes all developer tasks that have to be carried out in the Sprint
• Allows the team to organize all tasks
• Usually documented as index cards on a Meta Planning Board (Task Board)
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Sprint Backlog – Example from Video
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Development Sprint
• Normal Sprint in a Scrum project
• Implementation of all activities that are described in the Sprint
Backlog
– Design
– Coding
– Integration
– Test
– Documentation
– ...
• Documented in the Sprint Backlog (activity started / completed)
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Managing the Sprint Backlog
• Individuals sign up for work items (activities/tasks) of their own choosing
– Work is never assigned!
• Estimated work remaining is updated daily
• Team can add, delete or change work items in the sprint backlog
• Work for the sprint emerges
• If work is unclear, define a sprint backlog item with a larger amount of
time and break it down later
• Update work remaining as more becomes known
• Visualisation Burn-down chart
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Exploration Sprint
• For developing knowledge that is required
• For addressing risks, for example by creating a prototype
• For determining customer needs, e.g., by creating GUI mockups
• Important: Clear separation between exploration result and production
code
– The exploration result is discarded, no shippable product increment
is created!
• Exploration Sprints are usually shorter than normal development Sprints
• Rule of thumb: If teams spend more than 1/3 of its effort on exploration
activities, an exploration Sprint should be inserted
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Release Sprint
• Sprint at the end of a release cycle or the overall project
• Can combine tasks that would lead to large portions of non-
productive effort in a normal Development Sprint
– e.g., complex customer-specific configurations of the
product
• Create no added value from a customer perspective (since no
functionality is added)
– use seldom, keep short!
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Daily Scrum
• Parameters
– Daily
– 15-minutes
– Stand-up
• Not for problem solving
– Whole world is invited
– Only team members and Scrum
Master can talk
– Other roles may attend and listen
– Helps avoid other unnecessary
meetings
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Daily Scrum – 3 Questions
NB:
• These questions
are not status
reports for the
Scrum Master
• They are
commitments in
front of peers
What did you do yesterday? 1
What will you do today? 2
Is anything in your way? 3
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Sprint Review
• Typical duration: 1-2 hours
• Team presents all implemented
requirements
– At last the official build
– On a test environment that is as
similar as possible to the final
target environment
• Only fully and accurately
implemented requirements are
approved (-> shippable product
increment!)
– That means, 99% implemented
counts as not implemented
• Goal: Assessment of the
resulting work results and
approval by the Product Owner
• Participants:
– Team,
– Product Owner,
– Scrum Master,
– and possibly other stakeholders
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Sprint Retrospective
• Directly after the Sprint Review
• Concludes the Sprint
• Typically slightly longer than the
Sprint Review
• Reflection
– What went well?
– What has gone wrong?
– What could be improved and
how?
• Goal: Improve team collaboration
and the application of Scrum
• Participants:
– Team,
– Product Owner,
– Scrum Master,
– possibly other stakeholders or
managers (for the removal of
obstacles in the future)
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Sprint Retrospective
Taken from last year’s Industry Presentation (see course wiki of 2014): Challenges of Implementing SCRUM in a Large Scale Public Sector Project by Alar Huul (Nortal)
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Other Plans and Reports
• Release plan
– Documents the functionality (to be) shipped in product releases
• Speed of development report
– Documents development speed over Sprints
• Sprint burn-down charts
– Documents Sprint progress on a daily basis
• Obstacle Report
– Documents obstacles encountered
• Theme Park
– Provides thematic overview on completion status
• Final Sprint report
– Documents Sprint results
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Sprint Burndown Chart –
Example
(per
son
-ho
urs
)
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Sprint Burndown Chart –
Example Exercise: How many people are in the Scrum team? Assumptions: 1. Only 70% of the full capacity are
planned/allocated on day 0 2. A (work) day has 8 (work) hours
(per
son
-ho
urs
)
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Sprint Burndown Chart –
Example Exercise: How many people are in the Scrum team? Assumptions: 1. Only 70% of the full capacity are
planned/allocated on day 0 2. A (work) day has 8 (work) hours
Answer: 225 ph is ca. 70% of 320 ph 1 person works 8 x 20 = 160 ph per month Thus, there are probably 2 persons on the team
(per
son
-ho
urs
)
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Sprint Burndown Chart –
Example
Additional questions: 1. Is the number of tasks consistent with
that of SI? 2. Are there any new tasks added during
the sprint? 3. How do we know how much effort
was spent? 4. How could you check whether the
increase in remaining effort is a potential threat to successful sprint completion?
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Sprint Burndown Chart –
Example
Additional questions: 1. Is the number of tasks consistent with that of SI? Answer: Yes, 12 Tasks per person is within the range of 10-20 tasks per person at SI (even if we assume that 12 is only 70%)
(per
son
-ho
urs
)
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Sprint Burndown Chart –
Example
Additional questions: 2. Are there any new tasks added during the sprint? Answer: No, doesn’t look like; whenever a task is done, the number of remaining tasks drops accordingly.
(per
son
-ho
urs
)
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Sprint Burndown Chart –
Example
Additional questions: 3. How do we know how much effort was spent? Answer: Since we know how many people are on the team (and we don’t allow overtime): Spent Effort = 2 x #Days x 8 ph
(per
son
-ho
urs
)
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Sprint Burndown Chart –
Example
Additional questions: 4. How could you check whether the increase in remaining effort is a potential threat to successful sprint completion? Answer: Put a hypothetical Ideal burndown line from 320 ph down to 0 ph (at day 21) and check whether remaining effort crosses the line.
(per
son
-ho
urs
)
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Scrum: Prerequisites and Risks/Challenges
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Scrum: Prerequisites and Risks (1/2)
• Scrum has a different perspective on employees, management,
distribution of power as compared to traditional project management
approaches
– In particular, higher and top-level management must understand and
actively support Scrum
• Organizational culture
– Scrum requires openness, honesty, respect for each other
– In organizations with internal political power-play this might be missing
• Customer also must re-think their role
– Close involvement through many iterations is often unfamiliar
– Creates additional work on the client side
– Not every customer wants to see the creation of the product
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Scrum: Prerequisites and Risks (2/2)
• Partitioning of the product
– Product must be partition-able so that it can actually be developed
incrementally
– For example, this is not possible in certain regulated industries that
have to certify full requirements specifications very early
– Not all requirements can be partitioned equally well
– In particular, non-functional requirements, such as performance,
safety, security are difficult to partition – and must therefore be re-
examined in each iteration (integration) and ensured
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Scalability of Scrum
• Typical individual team is 7
± 2 people
– Scalability comes from
teams of teams
• Factors in scaling
– Type of application
– Team size
– Team dispersion
– Project duration
• Scrum has been used on
multiple 500+ person projects
(e.g., SAP)
Scrum of Scrums of …
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Structure of Lecture 06
• Scrum
• Choosing the right process (model)
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Choosing a Process (Model) is Difficult !
• To make the choice it is important to know your
organization/project.
– What characteristics does the project have?
– What characteristics affect the choice of the process
(model)?
– Can we use the same process (model) everywhere, or do
we need variants (a repertoire of different process models)?
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
How Much Structure is needed?
Size (organization)
Big Small
Size (product)
Big Small
Age (team)
Low High
Problem complexity
Big Little
Demand for precision
Big Little
Project length
Long Short
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
How Much Structure is adequate?
Formality of product (specification/validation)
Process discipline (support/enforcement)
Low High
Strict Low
Communication
Formal Informal
Number of check points
Many Few
Experience
Much Little
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
How much Agility is Recommended?
• Source: Boehm, B.; Turner, R.: Observations on balancing discipline and agility,
Proceedings of the Agile Development Conference, 2003. ADC 2003. Page(s):32-39
Criteria: - Personnel - Dynamism - Culture - Size - Criticality
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
How much Agility is
Recommended?
• Source: Boehm, B.; Turner, R.: Observations on
balancing discipline and agility, Proceedings of the
Agile Development Conference, 2003. ADC 2003.
Page(s):32-39
Criteria: - Personnel - Dynamism - Culture - Size - Criticality
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
How much Agility is Recommended?
• Source: Boehm, B.; Turner, R.: Observations on balancing discipline and agility,
Proceedings of the Agile Development Conference, 2003. ADC 2003. Page(s):32-39
Criteria: - Personnel
- Level 2&3: 20% - Level 1B: 30%
- Dynamism - Requ.-change/month: 10%
- Culture - Thriving on chaos: 30%
- Size - #personnel: 60
- Criticality - Loss due to defects:
essential funds Mixed Profile
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Alistair Cockburn – Project Categorizing
“Any one
methodology is
likely to be
appropriate for only
one of the boxes on
one of the planes.
Thus, at least 150
or so methodologies
are needed!” [Alistair Cockburn: Selecting a
Project 's Methodology. IEEE
Software 17(4): (2000)]
MTAT.03.243 / Lecture 06 / © Dietmar Pfahl 2015
Next Lecture
• Topic: SPI & Measurement – Part A
• For you to do:
– Tell me whether you want to do your project as a pair
– Continue working on Homework 2
• Use the submission button on the course web-page
• Deadline: Monday, 16-Mar-2015 at 20:00 (sharp!)
Recommended