0% found this document useful (0 votes)
9 views39 pages

Lecture8 MMZ SE 2018

The document discusses key concepts in software engineering, specifically focusing on velocity and burndown charts used in Agile methodologies. It explains how velocity measures a team's work capacity during sprints and how burndown charts track project progress and remaining work. Additionally, it outlines practical lab submissions and documentation requirements for a practical exam.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views39 pages

Lecture8 MMZ SE 2018

The document discusses key concepts in software engineering, specifically focusing on velocity and burndown charts used in Agile methodologies. It explains how velocity measures a team's work capacity during sprints and how burndown charts track project progress and remaining work. Additionally, it outlines practical lab submissions and documentation requirements for a practical exam.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 39

Software Engineering

2018

Mona M. Zaki
Lecture #8
15th April 2018
Today

• Velocity
• Burn down charts
• Examples and discussion
• Lab submission
• Practical exam documentation submission

15/04/2018 Dr Mona M. Zaki, Computer Science 2


Velocity
• The velocity of a team is a measure of how much work
that the team can handle within a specific time period,
i.e. how much of the product backlog can be completed
by the team in a sprint

• Velocity can be calculated on the basis of story points,


business value, hours, or any numeric field of your
choice

15/04/2018 Dr Mona M. Zaki, Computer Science 3


15/04/2018 Dr Mona M. Zaki, Computer Science 4
Velocity Estimation
• The velocity can be estimated as the average,
over several recent sprints, of the sum of the
estimates for the amount of work completed by
a team per sprint
• A team's recent velocity can be useful in helping
to predict how much work can be completed by
the team in a future sprint and improve team’s
performance

15/04/2018 Dr Mona M. Zaki, Computer Science 5


the velocity = (37 + 47 + 50 +57) / 4 = 48
15/04/2018 Dr Mona M. Zaki, Computer Science 6
Burndown Charts
• Monitor team performance and a project progress
• The chart can help in answering the following
questions:
- How good is this team with the planning?
- How well is this team executing against the planned
stories in a Sprint?
- Is this team self-organised and are they working in
union as a "team"?
- What improvements can this team make?
15/04/2018 Dr Mona M. Zaki, Computer Science 7
Why ?
• In Agile it helps to have a set of charts giving a deep
understanding of the product status and the effort
made and remaining

• The Burndown chart is such a fundamental metric

15/04/2018 Dr Mona M. Zaki, Computer Science 8


What is it?
• In definition it is a display of what work has been
completed and what is left to complete
• Shows the actual and estimated amount of work to
be done in a sprint
• Use it to track the total work remaining and to
project the likelihood of achieving the sprint goal
and to act accordingly

15/04/2018 Dr Mona M. Zaki, Computer Science 9


What is it?
• To track product development using the
Burndown chart, teams can use:
– a sprint Burndown chart (one for each developer or
work item and updated every day)
– a release Burndown chart (shows overall progress
and updated at end of each sprint)

15/04/2018 Dr Mona M. Zaki, Computer Science 10


Sprint Burndown Chart
• Teams use it to track the product
development effort remaining in a sprint
• General speaking it should consist of:
– X axis to display working days
– Y axis to display remaining effort
– Ideal line effort visualising expected progress as a
guideline
– Real line effort visualising current progress of effort

15/04/2018 Dr Mona M. Zaki, Computer Science 11


15/04/2018 Dr Mona M. Zaki, Computer Science 12
Sprint Burndown Chart
• At the start of an iteration/sprint the team
estimates the work for all the tasks it commits to

• The sum of all the hours estimated in story


points for all the tasks is the starting point for
the graph.

15/04/2018 Dr Mona M. Zaki, Computer Science 13


Sprint Burndown Chart
• Every day as the team members work on tasks, the
remaining work plotted on the chart should also reduce

• The chart should be updated each day and the graph


should ideally displays a downward trend

• What makes the chart an effective reporting tool is that


it shows the team's progress towards the Sprint Goal,
NOT in terms of time spent but in terms of how much
work remains
15/04/2018 Dr Mona M. Zaki, Computer Science 14
Tasks Mon Tue Wed Thu Fri
Code the user interface 8 4 8
Code the middle tier 16 12 10 7
Test the middle tier 8 16 16 11 8
Write online help 12

50
40
30
Hours

20
10
0
Mon Tue Wed Thu Fri
15/04/2018 Dr Mona M. Zaki, Computer Science 15
i. The number of stories
The number of items/stories on the Y axis. Problems?

stories require different


effort to be completed

the chart does not explain


the real iteration status

15/04/2018 Dr Mona M. Zaki, Computer Science 16


ii. Time unit
Time unit (hours or days) represents remaining time
necessary for completion (Most common). Problems?

It leads to micromanagement

15/04/2018 Dr Mona M. Zaki, Computer Science 17


iii. Remaining size
display the remaining size of all stories in a sprint backlog
that needs to be done, using story points. Problems?

Such stairs are


usually not
evaluated
correctly by
management

15/04/2018 Dr Mona M. Zaki, Computer Science 18


Burndown Example 1
Sprint commitment met , smooth progress over sprint
Burndown Example 2
Sprint commitment not met, slower pace and may not be able to
complete all the commitments on time.
Burndown Example 3
Sprint commitment met early before time, teams are going at a better
rate and may be able to finish earlier. The stories were probably
overestimated; therefore, the team finished them earlier.
Burndown Example 4
No work being performed
Sprint 1 Burndown

60

50

40
Hours remaining

30

20

10

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint
Burndown Example 5
Work being performed, but not fast enough
Sprint 1 Burndown

49

48

47

46
Hours remaining

45

44

43

42

41

40
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint
Burndown Example 6
Work being performed, but too fast!
Sprint 1 Burndown

60

50

40
Hours remaining

30

20

10

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint
Think!
What does a Burndown chart show?
1. Total Estimate
It is the sum of efforts in hours of all the user-stories,
basically it’s the total number of works in hours to
which the team is committed to
2. Amount of work Remaining or Effort Remaining
- This is what burn down shows and this is how this
graph get its name, in literal meaning it is the “effort
burndown chart”
- The Team will burndown some effort each day so that
on last day of sprint or release there is no work effort
remains
What does a Burndown chart show?
3. Working Days

- Since team need to calculate and carefully work on the


commit item each day, so that is the reason total days of
commitment of work are shown in graph

- This is the total working days in a sprint (excluding


holidays, weekend, etc.). This is actually your sprint
duration
What does a Burndown chart show?
4. Ideal Effort

- The ideal effort is drawn as a guide for a team, its


drawn by calculating the exact amount of effort
remaining which team need to burndown

- That is the reason you see a very straight line from the
top of Y-axis to X-axis, which is the last day of your
sprint
What does a Burndown chart show?
5. Real Effort
- Effort remaining line varies from team to team and day
to day

- It depends on how much effort remaining is added or


reduced each day

- If more items (user stories and issues) are added after


the sprint started, this show as an upward spike
Release Burndown Chart
• A released product should meet the functionality
requirements and the quality expectations of the
customer
• A release usually consists of one or several equally
sized sprints
• A release burndown chart provides an overview of the
release progress by plotting the remaining workload,
often referred to as the remaining effort in Scrum, at
the end of every sprint against the ideal workload
(or effort)
Release Burndown Chart
• The sprints are plotted on the x-axis, and the
remaining effort - on the y-axis

• The effort can be measured in hours, days or story


points

• Scrum master is responsible to update the release


burndown chart with the actual progress at the end of
each sprint, before the next sprint starts
Example
• A development team at X, Inc. is creating a new
operating system for the company's best-selling
smartphone, iX. The work is split into two-week
long sprints. It has been estimated that 4 sprints,
or 8 weeks of effort, are required before the first
version of the operational system will be ready
for releasing to customers.
Example cont.
• There are three people on the team. With each
team member producing 6 hours of effort daily
(equal to 30 hours weekly), the total ideal effort
per week is 3 x 30 = 90 hours.
• This equals 180 hours per two-week long sprint
and 720 hours for the release
• The release burndown chart can be displayed
as a line or a bar chart
Release Burndown Chart Example
• The red line plots is
the ideal effort,
assuming the same
amount of work is
accomplished during
each sprint

• The blue line show


the remaining effort
• In case the blue
line or bars are below
the red line =>
the team managed to
complete more tasks
during the sprint than
Planned, during each
sprint
• If the blue line are
above the red line =>
the team is behind the
schedule and the tasks
are taking more to
complete than planned
• Alternatively, new
tasks might have been
added to the sprint
To Submit in Lab
• Today and last Thursday :
– Story points for user stories : submission and
discussion
– Half of Sprint 3: submission and discussion
• Thursday this week and Sunday next week:
– End of sprint 3: submission and deliverables
– Velocity calculated for sprints (old) + estimated for
rest of sprints
– Sprints burn down charts (start from sprint 2)
– Release burn down chart (prepare it to be in progress)
15/04/2018 Dr Mona M. Zaki, Computer Science 37
For Practical Exam
• Print and deliver the following documentation MAX the
29th April per team in labs to your TA’s:
– Project Title + Scenario + Plan
– Team names + roles (per sprint)
– Functional, non-functional and constraints requirements
– Events (sprints/stories/tasks) scheduling
– Product backlog
– User stories (story points and priority points)
– Each sprint Plan + sprint backlog + sprint review+ sprint
retrospective
– Team velocity for each sprint + Burndown charts (sprints and
release)
15/04/2018 Dr Mona M. Zaki, Computer Science 38
15/04/2018 Dr Mona M. Zaki, Computer Science 39

You might also like