FutureOfAgile

Tips, Tricks and Experiments:
How to pick a story, start a sprint and get
the work done.
The Future of Agile Symposium
Rob Healy
27 October 2016

About Ammeon
www.ammeon.com © 2016 Ammeon Ltd. All Rights Reserved. Confidential - Do Not Distribute.
2
Our Focus
Accelerating service
delivery through
transformation
Our Capabilities
We are a services and
solutions company
offering Consultancy,
Training, Development,
Testing and Managed
Services
Our Team
We have a team of 200+
DevOps, Open source,
Cloud, IT and network-
experienced people
Our Locations
Dublin, Belfast, Belgrade,
Reading, Stockholm

Some of our customers
3

About me
4

Product Owner, Engineer, Wannabe Farmer
5
• Product Owner of two scrum teams. CPO, PSM,
Greenbelt Lean Six Sigma Experience in Kanban, Scrum,
CI/CD DevOps, FollowTheSun, SAFe, multiple Waterfall
to Agile transformations
• Co-founder of the Agile & Entrepreneurship (A&E)
meetup. Founder member of the Agile-Lean Ireland (ALI)
society. Member of Engineers Ireland
• From rural Roscommon. PRO of Rathangan Macra Na
Feirme

6
Tip:
How to PICK a Story

PICK a Story
7
All agile methodologies require a
prioritised backlog of work. This
backlog might be subtasks, user
stories, epics and so on.
My Backlog
Increasing
Priority

PICK a Story
8
• All agile methodologies require a
prioritised backlog of work. This
backlog might be subtasks, user
stories, epics and so on.
• Usually the backlog is prioritised
by business value and then either
an estimate of time / effort
required or the tickets broken
down in Goldilocks Estimation
(#NoEstimates)
My Backlog
Sprint 1
Sprint 2
Sprint 3+ ?

Now, PICK a Story
9
Implement Challenge
Possible Kill
High
Low
Payoff
HardEasy Effort

Observed Benefits
of PICK?
10
• A visual technique to visualise work in two-
dimensions (effort and value)
simultaneously.
• Useful for brainstorming with team /
stakeholders and getting buy-in on what is
the next most important piece of work and
why.
• Identifies the almost impossible and the not
really needed and encourages work on the
valuable and achievable.
Issues closed during 26 Feb review of Team
Lumberjacks backlog

11
Experiment:
When to start (and end) a sprint?

12
• The Ishikawa / Fishbone diagram with the 6Ms suggest there are 5
areas to be considered when planning a sprint and probably 4 in
the software industry
• Of these 4 areas two are major costs to the project, the manpower
and the machinery (development and test) required.
 Decisions on when to start a sprint need to focus on maximising
output and minimising costs
Effect of
Problem
occuring
Man: Method: Measurement:
Machine:Mother Nature:Materials:
What could possibly go wrong?

Some Assumptions
13
• An example project uses a three week sprint cycle starting on a Monday and ending on a
Friday.
• The engineers (Dev, Ops and Test) work a standard 40 hour working week, Monday to Friday.
• The hardware is available (apart from maintenance) 24 hours a day 7 days a week.
• The aim is to continuously deliver a new potentially shippable ISO every weekday and run a
series of Continuous Integration test loops every day to achieve this.
• Not all tests take the same amount of time, most take a minute or less but some take several
hours to execute
• The final deliverable is delivered after the last day of the sprint after all tests have passed and
all features have achieved a Definition of Done.
• Demo / Retro for previous sprint and Sprint Planning are all completed on the first day of the
sprint.

What is the best day to start?
14
Start on Wednesday of Week 1
• The limiting factors on the project are the cost of the
engineers and the cost of the hardware on which to
develop the software and run the automated tests.
• To optimise the resources it makes sense to use the
hardware of development, test authoring and
debugging issues during the 8 hour working day and to
run automated test suites in the 16 hour interim
periods.
• Run longer tests at the weekends with debugging on
Monday.
• Also resists shifting cadences from public holidays,
sickness and vacation
Mon Tues Wed Thur Fri Sat Sun
Wk 1
Wk 2
Wk 3
Wk 4

15
Trick:
When will we be done?

Our old definition
of done
16
• A correct, agreed and published list.
• Flagged as important and mostly ignored
• Often not considered until the very last
minute where someone could check the
DoD and argue whether the criteria were
met.
• Elements of “Broken Window” Syndrome.
For some stories the criteria didn’t apply
which undermined the entire document.

17
• A living document updated for each story and as it progresses
• Gives a single point for the status of each story to team members
• Shows past successes, where deviations were necessary and
current blockers
• Very successful, widespread adoption by teams
Story ID Status Code
on
ISO?
All
Tests
Pass?
Doc.
Review
ed?
Tasks
Closed
?
PO
Demo
done?
Stake.
Notified
?
Notes
TKT-111 Yes Yes Yes No Yes Yes
TKT-105 Some No Blocking bug
open
TKT-198 Yes No Some No No No
TKT-059 Yes Yes Yes Yes Yes Yes Done: 12 Oct
TKT-056 N/A Yes Yes Yes Yes N/A Doc only: 4 Oct
Our new Definition of Done

www.ammeon.com Ammeon@ammeon
Thank You

FutureOfAgile

Recommended

Recommended

More Related Content

What's hot

What's hot (6)

Viewers also liked

Viewers also liked (20)

Similar to FutureOfAgile

Similar to FutureOfAgile (20)

More from Rob Healy

More from Rob Healy (8)

FutureOfAgile