Software Construction & Design 1
The University of Sydney Page 1
Agile Software
Development Practices
(SOFT2412/COMP9412)
Estimation and Its Challenges;
Tools and Technologies for
Tracking Progress
Dr. Basem Suleiman
School of Computer Science
The University of Sydney Page 2
Agenda
– Planning in Traditional Software Development
– Planning in Agile Development
– Estimation in Agile Development
– Story Points, Ideal/Elapsed Time
– Velocity
– Tracking Project Progress
– Burndown charts, Velocity Charts
– Tools for tracking progress
– JIRA Agile
The University of Sydney Page 3
Plan-and-document Software
Development
The University of Sydney Page 4
Plan-and-Document Software Methodologies
– Typical phases in traditional software development methodologies
Ian Sommerville. 2016. Software Engineering (10th ed. Global Edition). Pearson
The University of Sydney Page 5
Plan-and-Document Software Methodologies
– Goal is to make Software Engineering predicable in budget and schedule
– Requirements elicitation
– Requirements documentation
– Cost estimation
– Scheduling and monitoring schedule
– Change management for requirements, cost and schedule
– Ensuring implementation matches requirement features
– Risk analysis and management
The University of Sydney Page 6
Plan-and-Document – Requirements Engineering Process
Ian Sommerville. 2016. Software Engineering (10th ed. Global Edition). Pearson
The University of Sydney Page 7
Requirements Documentation
– Software Requirements Specifications (SRS) process
– 100s of pages, IEEE 830-1998 standard recommended practice for SRS
– Stakeholders to read SRS document, build basic prototype, or generate test
cases to check:
– Validity: are all requirements necessary?
– Consistency: do requirements conflict?
– Completeness: are all requirements and constraints included?
– Feasibility: can requirements be implemented?
– Estimate budget and schedule based on the SRS
The University of Sydney Page 8
Why Software Projects Fail?
– Over-budget, over-time
– Hard to maintain and evolve
– Useless (unwanted) product features
– Standish group’s CHAOS report:
• 45% of features never used, 19% rarely used
– Development teams would build software, and throw it over the wall to their
users, and hope some of what they build would stick
https://www.projectsmart.co.uk/white-papers/chaos-report.pdf
https://www.projectsmart.co.uk/white-papers/chaos-report.pdf
The University of Sydney Page 9
https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects
Software Failures – Budget, Schedule, Requirements
Project Duration Cost Failure/Status
e-borders (UK Advanced
passenger Information System
Programme)
2007 – 2014 Over £ 412m
(expected), £742m
(actual)
Permanent failure – cancelled after a
series of delays
Pust Siebel – Swedish Police
case management (Swedish
Police)
2011 – 2014 $53m (actual) Permanent failure – scraped due to poor
functioning, inefficient in work
environments
US Federal Government
Health Care Exchange Web
application
2013 –
ongoing
$93.7m (expected),
$1.5bn (actual)
Ongoing problems – too slow, poor
performance, people get stuck in the
application process (frustrated users)
Australian Taxation Office’s
Standard Business Reporting
2010 –
ongoing
~$1bn (to-date),
ongoing
Significant spending on contracting fees
(IBM & Fjitsu), significant scope creep and
confused objectives
https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects
The University of Sydney Page 10
Planning in Agile
Software Development
The University of Sydney Page 11
Agile Manifesto – Planning
– “We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value”
– Individuals and interactions over processes and tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
– The items on the left are more valued than those at the right
Agile Manifesto: http://agilemanifesto.org/
© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.
http://agilemanifesto.org/
The University of Sydney Page 12
Agile Principles – Planning and Estimation?
9. Continuous attention to technical
excellence and good design
enhances agility.
10. Simplicity–the art of maximizing
the amount of work not done–is
essential.
11. The best architectures,
requirements, and designs emerge
from self-organizing teams.
12. At regular intervals, the team
reflects on how to become more
effective, then tunes and adjusts its
behavior accordingly.
5. Build projects around motivated
individuals. Give them the environment and
support they need, and trust them to get the
job done.
6. The most efficient and effective
method of conveying information to
and within a development team is
face-to-face conversation.
7. Working software is the primary
measure of progress.
8. Agile processes promote sustainable
development. The sponsors, developers,
and users should be able to maintain a
constant pace indefinitely.
1. Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements,
even late in development. Agile
processes harness change for the
customer’s competitive advantage.
3. Deliver working software frequently,
from a couple of weeks to a couple of
months, with a preference to the shorter
timescale.
4. Business people and developers
must work together daily throughout
the project.
Agile Alliance: http://www.agilealliance.org
Which Principles relate to planning and estimation in Agile Software Development ?
http://www.agilealliance.org/
The University of Sydney Page 13
Agile Principles – Relation to Planning?
9. Continuous attention to technical
excellence and good design
enhances agility.
10. Simplicity–the art of maximizing
the amount of work not done–is
essential.
11. The best architectures,
requirements, and designs emerge
from self-organizing teams.
12. At regular intervals, the team
reflects on how to become more
effective, then tunes and adjusts its
behavior accordingly.
5. Build projects around motivated
individuals. Give them the environment and
support they need, and trust them to get the
job done.
6. The most efficient and effective
method of conveying information to
and within a development team is
face-to-face conversation.
7. Working software is the primary
measure of progress.
8. Agile processes promote sustainable
development. The sponsors, developers,
and users should be able to maintain a
constant pace indefinitely.
1. Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements,
even late in development. Agile
processes harness change for the
customer’s competitive advantage.
3. Deliver working software frequently,
from a couple of weeks to a couple of
months, with a preference to the shorter
timescale.
4. Businesspeople and developers
must work together daily throughout
the project.
Agile Alliance: http://www.agilealliance.org
http://www.agilealliance.org/
The University of Sydney Page 14
Planning in Software Development
– Plan-driven (plan-and-document or heavy-weight)
– All of the process activities are planned in advance and progress is measured
against this plan
– Plan drives everything and change is expensive
– Agile processes (light-weight)
– Planning is incremental and continual as the software is developed
– Easier to change to reflect changing requirements
The University of Sydney Page 16
Scrum – Team Structure
Which team structure better reflect planning and estimation in Agile development?
Team A Team B
The University of Sydney Page 17
Scrum – Planning
The University of Sydney Page 19
Scrum – Planning
Can planning be changed (e.g.,
adding/removing user stories to a
Sprint) during development?
The University of Sydney Page 20
Agile Methods for
Estimating Size
Story points and Ideal Days
The University of Sydney Page 21
Estimating Size in Agile Development
– Agile teams separate estimates of size from estimates of duration
Estimating the duration of a project begins with estimating its size.
The University of Sydney Page 22
Requirements in Agile Software Development
– Requirements are also crucial for planning in Agile development
– Work continuously and closely with stakeholders to develop requirements
and tests
– Iterative development
– Short iterations 2-4 weeks each focused on core features
– Maintain working prototype while adding new features
– Check with stakeholders what’s next to validate building the right software
– Initial planning and estimation and adapt during development
The University of Sydney Page 23
User Stories – Base for Better Estimation and
Monitoring
– User stories (and tasks) and condition of satisfaction
The University of Sydney Page 24
Estimation – Story Points
– Metric for the overall size of a user story, feature, or other piece of work
– A point value to each item is assigned
– No. of story points ~ the overall size of the story
– Estimation scale:
– Fibonacci series; 1, 2, 3, 5, 8, …
– Subsequent number as twice the number that precedes it: 1, 2, 4, 8, …
– Why?
– Measure of the user story only
– No emotional measurements
– Team velocity is considered
– Team members focus on solving problems based on difficulty not time spent
The University of Sydney Page 25
Estimation – Staring Story Points
– Two approaches:
– Smallest story (expected) is estimated at 1 story point
– Medium-sized story assigned a number somewhere in the middle of the
range you expect to use
– Estimating in story points completely separates the estimation
of effort from the estimation of duration
The University of Sydney Page 26
Sprint Planning Session using Story Points
– Start with the most valuable user stories from the product backlog
– Take a story in that list (ideally the smallest one)
– Discuss with the team whether that estimate is accurate
– Keep going through the stories until the team have accumulated enough
points to fill the Sprint
The University of Sydney Page 27
Why Story Points Work?
– Simple, not magic
– The team is in control of them
– They get your team talking about estimates
– Developer’s are not scared of them
– They help the team discover exactly what a story means
– They help everyone on the team become genuinely committed
The University of Sydney Page 28
Ideal Days vs Elapsed Days
– Ideal time and elapsed time are different
– American football game is 60 minutes; however 3 or more hours will
typically pass on a clock before a 60 minutes game is finished
– Time to do a development task without any interruptions is?
– Time to do a development task with work interruptions is?
The University of Sydney Page 29
Estimating in Ideal Days
– Ideal days
– The amount of time a user story will take to develop
– Elapsed days
– Requires considering all interruptions that might occur while working on
a user story
– Ideal days only is an estimate of size
The University of Sydney Page 30
Estimating in Ideal Days
– Associate a single estimate with each user story
– Not in four programmer days, two tester days, and three product owner
days, etc
– Express the estimate as a whole (i.e., nine ideal days)
The University of Sydney Page 31
Estimation Techniques
– Expert opinion (estimates based on opinion)
– Analogy: compare with other stories
– Disaggregation: splitting a story into smaller tasks
– Planning Poker: based on expert opinion, analogy, disaggregation and fun
The University of Sydney Page 33
Estimation Technique – Planning Poker
– Gamified technique to estimate effort/relative size of development in Agile
development
– The best way I’ve found for agile teams to estimate is by playing planning
poker (Grenning 2002)
Agile Estimating and Planning: Planning Poker – Mike Cohn
The University of Sydney Page 34
Planning Poker
– Aims to avoid individual influence/bias (think independently)
– Team discussion with mediation to consider different views
– Team involvement in planning increases commitment
– It combines expert opinion, analogy, and disaggregation into an enjoyable
approach to estimating that results in quick but reliable estimates
The University of Sydney Page 36
Considering Story Points over Ideal Days
– Story points help drive cross-functional behavior
– Story points are a pure measure of size
– Estimating in story points is typically faster
– My ideal days are not your ideal days
The University of Sydney Page 37
Re-Estimating
– Story points and ideal days helps you know when to re-estimate
– Re-estimate only when your opinion of the relative size of one or more
stories has changed
– Do not re-estimate solely because progress is not coming as rapidly you as
you’d expected
– Let velocity take care of most estimation inaccuracies
The University of Sydney Page 39
Considering Ideal Days over Story Points
– Ideal days are easier to explain outside the team
– Ideal days are easier to estimate at first
– Ideal days make velocity predictions easier
The University of Sydney Page 41
Estimating Progress
Velocity
The University of Sydney Page 42
Estimating Progress – Velocity
– A measure of a team’s rate of progress
– Sum the number of story points assigned to each user story that
the team completed during the iteration
– Example:
– A team completed 3 stories, 5 SPs each → velocity = 15
The University of Sydney Page 43
Estimation – of Number of Sprints
– Size estimate of the project: sum the SP estimates for all
desired features
– Divide size by velocity to arrive at an estimated number of
Sprits (iterations)
The University of Sydney Page 44
Velocity, Duration and Schedule – Exercise
– Sum of all user stories is 100 SPs
– Team’s velocity, based on past experience, is 11 SP per two-
week Sprint
– Work out the following estimates:
– How many iterations/Sprints ?
– Estimate of duration is?
– Project schedule?
The University of Sydney Page 45
Velocity, Duration and Schedule – Example
– 100 SPs
– Team’s velocity 11 SP per two-week iteration
– 9.1 iterations (either 10 iterations or find one point to remove)
– Let’s assume we go with10 iterations
– 1 iteration = 2 weeks → estimate of duration is 20 weeks
– Count forward 20 weeks on the calendar and that becomes our schedule
The University of Sydney Page 47
Estimating Velocity
– Use Historical values
– Run an Sprint (iteration)
– Make a forecast
The University of Sydney Page 48
Consideration for Historical Values
– Is the technology the same?
– Is the domain the same?
– Is the team the same?
– Is the product owner the same?
– Are the tools the same?
– Is the working environment the same?
– Were the estimates made by the same people
The University of Sydney Page 49
Run a Sprint
– Run an iteration (or two or three) and then estimate velocity
from the observed velocity during the one to three iterations
The University of Sydney Page 50
Velocity – Forecasting
– Estimate the number of hours that each person will be available to work on
the project each day.
– Determine the total number of hours that will be spent on the project during
the iteration.
– Somewhat randomly select stories and expand them into their basic tasks.
– Repeat until you have identified enough tasks to fill the number of
hours in the iteration.
– Convert the velocity determined in the prior step into a range.
The University of Sydney Page 51
Velocity – Planning and Estimation
– Inconsistent velocity over long time
– Hidden challenges not counted?
– Outside business/stakeholders’ pressure?
– Observe team velocity throughout the Sprints and investigate decrease in
average velocity (e.g., inefficiency)
– Discuss in the retrospective meetings
The University of Sydney Page 53
Tracking Project Progress
Burndown chart, The Task board
The University of Sydney Page 54
Burndown Charts
– Tracks the completion of development work throughout the Sprint;
– Should be visible to everyone in the team (e.g., whiteboard, wall chart,
online tool)
– First half of the Sprint planning
– Story points and velocity to figure out what will go into the Sprint
– Good estimation and planning should help the team to burn stories
relatively with similar pace
The University of Sydney Page 55
Burndown Charts based on Story Points
– x-axis: first and end dates of the sprint
– y-axis: story points (0 to 20% more than the total no. of points in the Sprint)
– The plot: a user story is “Done”, plot the number of points left in the sprint,
at the current day
– Fill in more days in the chart as more stories are finished
– More work needs to be added (discovered during daily scrum)
– Estimate amount of points to remove to balance out the Sprint
– Add card(s) to the task board, follow-up team meeting to estimate added work
– Add notes to the chart
– As you get close to the end of the Sprint, more points burn off the chart
The University of Sydney Page 56
Burndown Charts
– Burndown chart when the Sprint starts
The University of Sydney Page 57
Burndown Charts based on Story Points (1)
Two stories worth 7 points burned off
Ideal burndown
The University of Sydney Page 58
Burndown Charts based on Story Points (2)
The Product Owner added stories
halfway through the sprint
The University of Sydney Page 59
Burndown Charts based on Story Points (3)
A gap between the burndown chart
and the guideline tells you that there’s
a good chance you won’t finish all of
the stories by the end of the sprint.
The University of Sydney Page 66
Tracking Project Progress
Burndown chart, The Task board
The University of Sydney Page 67
Tool Support for Agile SW Development
https://www.atlassian.com/software/jira/agile
– JIRA Agile is a software tool for planning, tracking and managing software
development projects
– Supports different agile methodologies including Scrum and Kanban
– Jira Software supports Scrum Sprint planning, stand ups (daily
scrums), Sprints and retrospectives
– Including backlog management, project and issue tracking, agile reporting
• E.g., Burndown and velocity charts, Sprint report
– Scrum boards visualize all the work in a given Sprint
– Agile plugins such as GreenHopper, Agile Methods and Reports.
The University of Sydney Page 68
Jira Agile – Scrum Board
https://www.atlassian.com/software/jira/agile
The University of Sydney Page 69
Jira Agile – Sprint planning
https://www.atlassian.com/software/jira/agile
The University of Sydney Page 70
Jira Agile – Burndown Charts
https://www.atlassian.com/agile/tutorials/burndown-charts
estimation in
story points
amount of work
left
Guideline;
ideal progress
The University of Sydney Page 71
Jira Agile – Velocity Chart
https://confluence.atlassian.com/jirasoftwareserver/velocity-chart-938845700.html
The University of Sydney Page 72
References
– Andrew Stellman, Margaret C. L. Greene 2014. Learning Agile:
Understanding Scrum, XP, Lean and Kanban (1st Edition). O’Reilly, CA, USA
– Mike Cohn. 2005. Agile Estimating and Planning. Prentice Hall PTR, Upper
Saddle River, NJ, USA.