Agile Software
Development Practices
(SOFT2412/COMP9412)
Estimation and Its Challenges; Tools and Technologies for Tracking Progress
Dr. Basem Suleiman
School of Information Technologies
The University of Sydney
Page 1
Agenda
– Planning in Traditional Software Development
– Planning in Agile Development
– Estimation in Agile Development – StoryPoints,Ideal/ElapsedTime
– Velocity
– Tracking Project Progress
– Burndowncharts,VelocityCharts
– Tools for tracking progress – JIRAAgile
The University of Sydney
Page 2
Plan-and-document Software Development
The University of Sydney Page 3
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 4
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
– Ensuringimplementationmatchesrequirementfeatures
– Risk analysis and management
The University of Sydney
Page 5
Plan-and-Document – Requirements Engineering Process
Ian Sommerville. 2016. Software Engineering (10th ed. Global Edition). Pearson
The University of Sydney Page 6
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 7
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
• Developers believe that software work exactly the way they intended it to work and users need to change their expectation to use it
https://www.projectsmart.co.uk/white-papers/chaos-report.pdf
The University of Sydney Page 8
Planning in Agile Software Development
The University of Sydney Page 9
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”
– Individualsandinteractionsoverprocessesandtools – Workingsoftwareovercomprehensivedocumentation – Customercollaborationovercontractnegotiation
– 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.
The University of Sydney
Page 10
Agile Principles – Planning and Estimation?
Discuss – which Principles relate to planning and estimation in Agile Software Development ?
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
9. Continuous attention to technical excellence and good design enhances agility.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
7. Working software is the primary measure of progress.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
4. Business people and developers must work together daily throughout the project.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
AgileAlliance: http://www.agilealliance.org
The University of Sydney Page 11
Agile Principles – Relation to Planning?
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
9. Continuous attention to technical excellence and good design enhances agility.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
7. Working software is the primary measure of progress.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
4. Businesspeople and developers must work together daily throughout the project.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
AgileAlliance: http://www.agilealliance.org
The University of Sydney Page 12
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 13
Requirements in Agile Software Development
– RequirementsarealsocrucialforplanninginAgiledevelopment
– 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 (verification)
– Initial planning and estimation and adapt during development The University of Sydney
Page 14
Requirements in Agile Development
– User stories (and tasks) and condition of satisfaction
The University of Sydney Page 15
Scrum – Planning
a 2 to 4 week iteration
Initial project estimate and planning
The University of Sydney
Page 17
2 to 4 weeks
Scrum – Planning
Could planning be changed during development?
The University of Sydney Page 18
Scrum – Team Structure
Which team organization better describes the Scrum Sprint/iteration planning?
The University of Sydney Page 19
Agile Methods for Estimating Size
Story points and Ideal Days
The University of Sydney Page 20
Estimating Size in Agile Development
– Agile teams separate estimates of size from estimates of duration
The University of Sydney
Page 21
Estimating the duration of a project begins with estimating its size.
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 22
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 23
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 24
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 25
Ideal Days vs Elapsed Days
– Ideal time and elapsed time are different
– Americanfootballgameis60minutes;however3ormorehourswill
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 26
Estimating in Ideal Days
– Idealdays
– The amount of time a user story will take to develop
– Elapsed days
– Requires considering all of the interruptions that might occur while
working on a user story
– Ideal days only is an estimate of size
The University of Sydney
Page 27
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 28
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 29
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
https://www.youtube.com/watch?v=MrIZMuvjTws
The University of Sydney Page 30
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 31
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 33
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 34
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 36
Velocity
The University of Sydney Page 38
Estimation – 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 39
Estimation – of Number of Iterations
– Size estimate of the project: sum the SP estimates for all desired features
– Divide size by velocity to arrive at an estimated number of iterations
The University of Sydney
Page 40
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 iteration
– Work out the following estimates:
– How many iterations ? – Estimateofdurationis? – Projectschedule?
The University of Sydney
Page 41
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 42
Estimating Velocity
– Use Historical values
– Run an iteration/Sprint
– Make a forecast
The University of Sydney Page 44
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 45
Run an Iteration
– 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 46
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 47
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 48
Tracking Project Progress
Burndown chart, The Task board
The University of Sydney Page 50
Burndown Charts
– Tracks the completion of development work throughout the Sprint; how a Sprint is progressing at glance
– 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 51
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 52
Burndown Charts
– Burndown chart when the Sprint starts
The University of Sydney Page 53
Burndown Charts based on Story Points (1)
Ideal burndown
The University of Sydney
Page 54
Two stories worth 7 points burned off
Burndown Charts based on Story Points (2)
The Product Owner added stories halfway through the sprint
The University of Sydney
Page 55
Burndown Charts based on Story Points (3)
The University of Sydney
Page 56
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.
Tracking Project Progress
Burndown chart, The Task board
The University of Sydney Page 63
Tool Support for Agile SW Development
– Jira agile is a software tool for planning, tracking and managing software development projects
– Supports different agile methodologies including Scrum and Kanban
– JiraSoftwaresupportsScrumSprintplanning,standups(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.
https://www.atlassian.com/software/jira/agile The University of Sydney
Page 64
Jira Agile – Scrum Board
https://www.atlassian.com/software/jira/agile
The University of Sydney Page 65
Jira Agile – Sprint planning
https://www.atlassian.com/software/jira/agile
The University of Sydney Page 66
Jira Agile – Burndown Charts
estimation in story points
amount of work left
Guideline; ideal progress
https://www.atlassian.com/agile/tutorials/burndown-charts The University of Sydney
Page 67
Jira Agile – Velocity Chart
https://confluence.atlassian.com/jirasoftwareserver/velocity-chart-938845700.html
The University of Sydney Page 68
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.
The University of Sydney Page 69