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

Related slideshows

More Related Content

FutureOfAgile