Agile Development

Agile Development
Content
Scrum
Sprint planning
Conducting the sprint
Review meeting
Scrum
What is Scrum? How agile works need to remind

A subset of agile development

A lightweight process framework
A set of practices that should be followed to be consistent with the framework
By keeping the practices simple and lightweight more time can be spent on
the actual development
Time spent on paperwork is not productive
The most popular approach used in industry
Scrum Workflow
Product backlog
List of things that need to be done
Anyone in the team can add to this list
List items should be user stories (typically arranged in a user story map)
Can also include non-functional requirements such as improving performance or
fixing bugs
The product owner prioritises these after consultation with the rest of the team
Priorities regularly adjusted based on current business needs.
Sprint Backlog
Ordered list of Product Backlog Items (User Stories)
Team agrees to complete them during the coming Sprint
Taken from the Product Backlog during the Sprint Planning Meeting
Each story assigned a Point value based on the Estimated amount of relative effort
it will take to complete the story
No additions or changes until the Sprint ends.
Product Sprint
A time-based unit of development working software component

Restricted to a specific duration (timeboxed)

Duration of each sprint determined by team dynamics
Typically a week in length
Each sprint results in the delivery of working code
Scrum Master
Ensures that the team sticks to the scrum process
A mentor/coach
Familiar with the techniques
Has some previous experience
Responsible for resolving any issues.
Product Owner
Part of the development team
Aligned to the business
Clear understanding of the requirements of the problem domain
Responsible for prioritising work (user stories):
Discuss these with the team
Have to take the final decision
Key Steps in a Sprint
Sprint planning
Daily standups
Addressing problems
Sprint review
Retrospection
Takeaway
Scrum is the most popular agile methodology
Uses a timeboxed approach which results in regular delivery of working code
All members of the development team are involved in programming
Two key roles are scrum master and product owner.
Sprint Planning
Purpose
Regular meeting to create and plan a Sprint Goal
Everyone in the team must attend
Analyse first item from top row of the user story map:
Can it be achieved in the next sprint?
Identify 'stretch tasks'
Collaborative Workspace
Develop a team workspace
Use whiteboards / sticky notes to organise team
These should be easy to see:
by entire team
at all times
Track progress using:
Kanban board
Burndown chart
Clarifying Requirements
Customer is present:
Identify the user stories to be delivered:
Product owner describes each from a functional perspective
Whole team discusses and defines how it can be implemented
Captured on whiteboard or flip chart
Could be wireframes / UML or other
Clear explanation of how these will be tested.
Identifying Tasks
Carried out when customer has left:
Each story is broken down into technical tasks
Written on sticky notes (ideally different colours for different types of task)
Team estimate how long (hours/points) task will take them
Estimate written on the note.
Estimates are Guesses
High-level estimates should never be turned into hard commitments
Accurate up-front estimates are impossible
Can only answer one question
Is it possible to complete the sprint given the available resources?
Purpose of Estimation
To determine if the targets are realistic enough to allow the sprint to be controlled
to meet them
Not to predict outcome
Estimates can't give an accurate prediction of the future
—Steve McConnell, Software Estimation: Demystifying the Black Art.
Planning Poker
Wisdom of the crowd (James Surowiecki)
Each member of the team has cards representing different difficulties (typically 1, 3
and 5)
Each task is considered in turn
Team members decide (in secret) the difficulty
Reveal their choices
If different, discuss their rationales and choose again.
Cone of Uncertainty
Improving Estimation Accuracy
Relative Estimation – place stories in order of difficulty
Reflection – record time taken to complete stories
Triangulation – improve accuracy using actual duration of previous stories.
Kanban Board Need To Practice
Arrangement of columns to track work progress
Each column represents a step in the development process
Each user story:
split into logical chunks
tracked across the columns
Used to define next steps to be completed
Easy to identify progress and bottlenecks
Need To Practice
Burndown Chart
Updated before every Daily Standup Meeting
Scrum Master adds up the estimated hours for all remaining tasks on the Kanban
board
Aim is for this time to be zero by the end of the sprint
Plot this on a graph
Plan will be a straight line
Annotate with key events
Need To Practice
Shows the true project progress!
Y= Story points

Need To Practice
Takeaway
Agile planning is done in two stages, clarifying the user requirements followed by
technical planning
The Kanban board and burndown chart are key to monitor agile development and
should be always kept up to date.
Conducting the Sprint
Daily Standup Meeting
Carried out at the start of each day
Entire team must be present
Stand around the planning board
Up to date documentation (kanban and burndown charts)
Each member reports back:
What did they achieve since the last meeting?
What will they achieve before the next meeting?
Are there any issues holding them back?
Updating the Kanban Board
Make sure any tasks that have been carried out are in the correct columns
Identify any stalled tasks (mark the notes)
Identify any bottlenecks.
Updating the Burndown Chart
Add up the hours listed on cards not in the completed column of the Kanban
board
Plot this on the burndown chart.
average story points of a single sprint(iteration)
completed story points
Team Velocity
Addressing Problems
Daily standup not used to resolve issues
Issues are raised at the meeting
Resolved by the relevant subgroup immediately after the meeting
Subgroup should report back to Scrum Master to explain the resolution.
Interrupt Procedure
Product Owner decides there is a feature of higher business value to add to the
Sprint
Triggers the interruption procedure
Part of team assigned to handle this (triage)
If the interruption will have huge impact
Product Owner aborts the Sprint
Triggers a new planning meeting
Takeaway
Each sprint is over a fixed duration (normally a week)
Each begins with a planning meeting and ends with a retrospective which should
be attended by the client
Daily meetings mean issues can be resolved and documentation updated
There should be a system in place to handle urgent issues
Review Meeting
Sprint Review Meeting
Held at the end of each sprint to improve the the Product Backlog health.
Attended by product owner, Scrum team and client
Scrum team demonstrates the new features to the client
Assessed against the sprint goal
Kept very informal
A natural result of the sprint.
Retrospection
Takes place after the sprint review meeting and takes around an hour
The aim is to improve the way the team do things
The entire team including ScrumMaster product owner should participate
Each member should identify specific stuff the team should:
Start doing
Stop doing
Continue doing.
Takeaway
In agile, working software is used to measure success and needs to be
demonstrated to the customer at the end of each sprint
The retrospection meeting allows the team to learn from each sprint and improve
their practices which leads to better performance.