Agile Planning
Estimation: When will it be done?
On every project we need to answer questions like:
How many features will we complete by the target date? How long will the next release take to finish?
What can we deliver in the next iteration?
To answer these, we need to estimate the amount of work represented by user stories. The usual approach is to use an abstract estimate of size:
Story Points
COMP3297: Software Engineering 2
How long will it take? How much will it cost?
Agile approaches to estimation are very simple.
We know we don’t have perfect knowledge. We try to be reasonably accurate with the knowledge we have, but we understand there is no point trying to be precise.
Big difference from complex traditional cost/effort estimation models. For example, this was a very influential and popular model:
Then:
, where exponent
= 0.91 + 0.01
COMP3297: Software Engineering
3
Cone of Uncertainty
By skilled estimators
COMP3297: Software Engineering
This is best case accuracy. You can’t do better.
The only way to reduce the variability in estimates is to reduce the variability in the project.
4
Story Points
Estimating in Story Points:
– you are working with a relative measure during estimation.
Don’t try to translate into hours when estimating the number of story points. Raw value is not important – we care about relative value.
That makes estimation fast – people are better at relative estimation.
When velocity data available – story points per sprint for this development team – then we can convert the story point count of the backlog to the number of sprints to clear the backlog.
If you find an estimate was incorrect, don’t adjust retrospectively – it is all part of velocity range
COMP3297: Software Engineering 5
Estimating Story Points
Steps: the first step is an optional variation
[Sort the user stories very roughly in order of size and find the smallest]
Use a simple reference story and give it a value of 1. If no existing reference, use the smallest story in the list. Usually give that one a value of 2 in case smaller stories are discovered later (i.e. 1 or 0.5)
Next, pick a story. Everyone decides how big it is in comparison to those already estimated. We don’t need high precision. Discuss and repeat until there is consensus.
Use these numbers (Fibonacci-like) to give a size to each story
0.5, 1, 2, 3, 5, 8, 13, 20, 40 – limited choices so we don’t waste time trying to be overly precise.
[In reality: each bin represents a normal distribution of time.
1 Story Point could represent a range of 4–12 hours, 2 Story Points 10–22 hours and so
on. But the distribution is unknown during estimation.]
COMP3297: Software Engineering 6
What to consider
When estimating size, take into consideration:
the relative physical size – includes everything for the story to be considered “done”, not just designing and writing the code
See Definition of Done on the next slide
the relative complexity of the work for this team
the relative risk or uncertainty in doing the work – that is, the effort to deal with risk.
[For small projects, some experienced teams don’t need to estimate in Story Points. They are able to create PBIs that are small and of roughly the same size.
Then they simply count PBIs to estimate size.]
COMP3297: Software Engineering 7
How do we know we are done? Definition of Done.
These tasks should be done for almost all PBIs and increments. They take effort and will reduce the time available for other tasks.
Remember to take them into account when filling a sprint backlog. Do that by
increasing effort estimates for tasks that contain them, OR by treating them as
Code pushed to remote repo (or otherwise available in VCS) Code peer reviewed
Refactoring complete
Unit tests passed
Increment builds successfully Regression tests passed
Story acceptance tests passed
(functional and non-functional) Documentation updated
[Deployed, if doing continuous deployment]
overhead and therefore reducing the available capacity of the sprint.
COMP3297: Software Engineering 8
Sprint Backlog
Each User Story selected for a sprint is broken down into a set of tasks and estimated in effort-hours by the Developers.
First break the story down into smaller end-user functions if necessary.
Then, at the start of the sprint, split each story into tasks. For database-backed web applications like ours, tasks typically include:
Test Design,
Database development (Models in Django) ,
Business Logic development (probably Django Views at the moment),
UI development (Templates + Forms in Django), Refactoring
COMP32Q97u:iScokftwlyaredEinsgcinoeevriengrwhatyoudon’tknow. 9
An alternative is: Analyse, Design, Code, Test
Sprint Backlog
Tasks are the smallest units of work used in Sprint Planning. They are single-person and can be finished in a day or less.
Some teams don’t estimate in person-hours, but just create every task to be about a day or half a day of work.
In general, keeping tasks to around a day helps:
• Set a good rhythm that matches the daily stand-up frequency
• Better transparency among team members. Better rate of inspection
and adaptation
• No place to hide!!
COMP3297: Software Engineering 10
How do we know a PBI in the Product Backlog is ready to be developed?
They must be ready for development before the Development Team can commit to complete them in the sprint.
That means they must satisfy several criteria before they can be brought into a Sprint Backlog
Scrum includes a Definition of Done that a PBI must satisfy to be considered finished. But it does not include a Definition of Ready.
Most teams adopt one as a checklist for accepting PBIs into a sprint.
COMP3297: Software Engineering 11
Definition of Ready.
Since PBIs close to the top of the product backlog must be ready to enter the next sprint, they should conform to the INVEST criteria.
In particular:
Dependencies should be identified and none will block completion of the PBI in the sprint. Related to (I)
Business value should be clearly understood. Related to (V) Has an estimate. Related to (E)
Small enough to complete in the sprint. Related to (S)
Acceptance criteria should be clear and testable, both functional and non-functional. Related to (T)
COMP3297: Software Engineering 12
Definition of Ready (cont.)
and, also:
The details of the PBI should be clear enough for the Developers to know that they have the required skills and can complete it.
The Scrum Team knows how they can demonstrate the PBI to stakeholders in the Sprint Review.
COMP3297: Software Engineering 13
Velocity-driven vs. Capacity-driven sprint planning
When your team knows its average velocity in story points per sprint it can provide a basis for planning
Velocity-driven:
PBIs are selected and added to the sprint plan while the sum of story points selected does not exceed the average velocity.
COMP3297: Software Engineering 14
Velocity-driven vs. Capacity-driven sprint planning
An alternative: Capacity-driven
Product Owner brings the current most important PBIs.
Dev team brings one in, breaks it roughly into tasks and estimates it in effort- hours.
If the team feels they can complete the work in the remaining hours available in the sprint, it is added to the plan.
Team continues with the next PBI until they reach the point where the tasks of the selected PBI cannot fit into the sprint.
Velocity-driven planning used to be the most common approach. Capacity-driven planning has proved more successful for many teams.
Velocity is probably best used for long-term planning rather than sprint planning.
COMP3297: Software Engineering 15
Sprint progress: Taskboard
COMP3297: Software Engineering 16
Progress is made visible to entire scrum team by task board and sprint burndown chart or table.
The famous Post-it version (not a Scrum artefact)
COMP3297: Software Engineering 17
Sprint Progress: Burndown table
Shows effort in hours remaining for each task at start of day.
May increase if task is found to be larger than the original estimate. Will stay unchanged if no progress, for example if it has not started yet. May need to add new tasks missed during original feature breakdown.
Tasks
Day 1
Day 2
Day 3
Day 4
Day 5
Day 6
Day 7
Day 8
Day 9
…
Day 15
Task 1
8
4
4
2
Task 2
12
8
16
14
9
6
2
Task 3
5
5
3
3
1
Task 4
7
7
7
5
10
6
3
1
Task 5
3
3
3
3
3
3
3
Task 6
14
14
14
14
14
14
14
8
4
Task 7
8
6
4
2
Tasks 8-30
151
139
143
134
118
99
89
101
84
TOTAL
200
180
190
175
155
130
115
113
90
COMP3297: Software Engineering 18
Sprint burndown chart
Plot the Totals to show burndown
COMP3297: Software Engineering 19
Agile Tracking.
Tracking Progress
The previous tool, the burndown (or burnup) chart, is the most common tool used to track progress in Scrum.
Very simple, and used to track:
Progress within each sprint, and Progress for the project as a whole.
We saw, a burndown chart shows the total amount of unfinished work that must be completed to achieve the sprint or release goal.
At the project level, we chart:
work remaining in story points against sprints
Within a sprint we chart:
estimated remaining effort against day in the sprint
COMP3297: Software Engineering 21
Project Level
Tracking fixed-scope release burndown
22
COMP3297: Software Engineering
21.5 25 19 velocities from team’s past
projects/sprints
Velocity of a sprint is the difference in work remaining at the end of the sprint compared with work at the beginning.
Projected to need 6, 7 or 8 sprints to complete the fixed scope backlog based on previous best, average, and worst velocity of the team
“Average” velocity: long term average over the most recent 8 sprints “Best” velocity: average of the best 3 out of the most recent 8 sprints “Worst” velocity: average of the worst 3 out of the most recent 8 sprints.
Projected velocity
Common averaging approach after completing several sprints for a project:
COMP3297: Software Engineering
Accommodating scope change – burnup
Burnup shows progress towards goal in a way that makes it easy to show change in scope of the release.
Change in scope
COMP3297: Software Engineering
Common to be constrained by a fixed release date: Fixed-date release burnup
Notice the Product Backlog is shown complete and is plotted upside-down.
Inverted full backlog shows features completed in each sprint.
Shows progress towards target set of features that will be delivered at the release date.
COMP3297: Software Engineering
Average, Best, Worst velocities of 33, 37, and 28 story points per sprint.
If there are 3 sprints remaining we can complete: likely 99, at best 111, and at worst 84 story points of work.
Can show where these intersect the backlog to show what features may be finished or may not.
Or can show as estimates of amount of current backlog that can be delivered within remaining schedule
Backlog is now the usual version, showing remaining PBIs.
Estimate
Will have
worst
likely best
Might have
Won’t have
COMP3297: Software Engineering
Enhanced burn-down charts
Alternative to burn-up charting
COMP3297: Software Engineering
27
Sprints
Trendlines for prediction
160 140 120 100
80 60 40 20
0 -20 -40
assumes an average scope increase after each iteration
Predict 7 sprints. No backlog predicted to remain at start of 8th
At an average velocity of 20 points/sprint
Range of estimates under different assumptions
7 910
7 8 9 10 11 12 13 14
12345
6
assumes no further scope increase after iteration 6
assumes an average scope increase from 5 onwards
COMP3297: Software Engineering
28
Trouble.
160 140 120 100
80 60 40 20
0 -20 -40 -60
7 8 9 10 11 12 13 14
Sprints
123
COMP3297: Software Engineering
4
5
6
Although would be easier to spot the problem with a regular burndown chart
29
The sample sprint burndown chart from earlier is in the regular form to show the progress towards the goals of the sprint clearly, but not the full picture.
Could show effects of changes in estimates and of added/removed tasks to give more complete insight30
Sprint burndown chart
COMP3297: Software Engineering
Sprint Progress: Burndown table
Tasks
Day 1
Day 2
Day 3
Day 4
Day 5
Day 6
Day 7
Day 8
Day 9
…
Day 15
Task 1
8
4
4
2
Task 2
12
8
16
14
9
6
2
Task 3
5
5
3
3
1
Task 4
7
7
7
5
10
6
3
1
Task 5
3
3
3
3
3
3
3
Task 6
14
14
14
14
14
14
14
8
4
Task 7
8
6
4
2
Tasks 8-30
151
139
143
134
118
99
89
101
84
TOTAL
200
180
190
175
155
130
115
113
90
COMP3297: Software Engineering 31
You will use Jira next-gen to plan and track your Group Project (or fake it!!):
It will help you manage your Product Backlog…
Note: Just a hypothetical backlog based roughly
on our pre-project to show a few features of Jira
next-gen. Only the Create Location and View COVID
Data stories would actually appear in your real pre-project. And, as mentioned, not in this order
COMP3297: Software Engineering
You will use Jira next-gen to plan and track your Group Project:
…and User Stories…
Attach Wireframe
Add (sub) tasks
COMP3297: Software Engineering
You will use Jira next-gen to plan and track your Group Project:
…and Sub-tasks…
COMP3297: Software Engineering
You will use Jira next-gen to plan and track your Group Project:
…and Sprints…
COMP3297: Software Engineering
…and Sprint Taskboard…
2
You will use Jira next-gen to plan and track your Group Project:
COMP3297: Software Engineering
And helps you track your sprints and your project as a whole
37
COMP3297: Software Engineering
Why do we use Jira in this course?
Why you need to know it:
COMP3297: Software Engineering Data from 2020 38
Would tool users recommend their tools?
COMP3297: Software Engineering 39