Agile
Planning
Learn to make Agile plans
THE GOAL OF THE DAY
How to build backlogs
Split epics to stories and tasks
WHY AGILE?
SOFTWARE PROJECTS ARE HISTORICALLY CHAOTIC
Schedule slips
Project cancellation
Quality spiral death
High defect rate
Business misunderstood
Staff turnover
HOW TO SOLVE?
Let's find a metaphor...
Engineering!
Adaptation:
WATERFALL
Planning
1 week
Analysis
2 weeks
Planning
2 weeks
Implementation
6 weeks
Testing & Fixing
3 weeks
DEMO
On Top of Everything
CHANGING REQUIREMENTS & CIRCUMSTANCES
THE AGILE WAY
Adaptive, not predictive
People-oriented, not process-oriented
Plan.
1 week
Analysis
2 weeks
Plan.
2 weeks
Impl.
6 weeks
Test
3 weeks
DEMO
$ $ $ $ $
Planning
1st week
Implementation
Test
DEMO
Classical or Waterfall development
Iterative development (small batch - feedback - improve - repeat)
of the most important feature
Planning
2nd week
Implementation
Test
DEMO
of the next important feature
Planning
3rd week
Implementation
Test
DEMO
of the next valuable feature
$
$ $ + $
Planning
4th week
Implementation
Test
DEMO
of the next feature
$ $ + $ + $
$ $ $ $ $ $ $ $ $
$ = "MONEY", LEARNING, FEEDBACK
OK AGILE...
BUT HOW?
CYCLES
ITERATION
(SPRINT)
PLANNING
RELEASE PLAN
EPICS
STORIES
TECHNICAL
TASKS
EXEC, PM
DEVELOPMENT, QA, UX, DATA
ITERATION
(SPRINT)
CYCLE
The goal is to know what problems we will solve
Speed + Quality + Price
Variables to manage a project
there is one more...
Scope
YOU NEED TO BE PART OF SCOPING...
PRODUCT THINKING
Content Blocks
CYCLE
The goal is to know what problems we will solve
EPIC
PROBLEM 1
EPIC
PROBLEM 2
EPIC
PROBLEM 3
CYCLE PLAN
-
Focuses on the problem and not the solution
-
Negotiable, scope can be changed
-
Expresses real customer value
-
Splittable to multiple stories
-
Framed from the user’s perspective
EPICS
HOW TO WRITE GOOD
EPIC
PROBLEM 1
CYCLE PLAN
EPIC
PROBLEM 2
EPIC
PROBLEM 3
CYCLE PLAN
HOW TO WRITE GOOD
-
Incrementally bring customer value
(even if it's small and temporary) -
Items can be swapped or replaced
-
Have realistic milestones with clear acceptance criteria, and business value
EPIC
PROBLEM 1
CYCLE PLAN
EPIC
PROBLEM 2
EPIC
PROBLEM 3
AT THE END OF THE CYCLE PLANNING
-
We know what problems we will solve and make a commitment to deliver a solution for them
-
We have estimations for the solutions
-
We have a high-level backlog for the cycle with epics and stories for at least the first few weeks
ITERATION
The goal is to know how
and when we will solve a committed problem
ITERATION
The goal is to know how and when we will solve a committed problem
EPIC
PROBLEM 1
EPIC
PROBLEM 2
EPIC
PROBLEM 3
CYCLE PLAN
USER STORY
BACKLOG
USER STORY
WHAT IS LIKE A GOOD
-
Have customer value
(even if it's small and temporary) -
Phrased from the customer perspective
-
Possibly optional, independent
-
Small enough to fit 2-3 stories in an iteration
-
It's small enough to be able to make a good enough estimation
USER STORY
HOW TO WRITE A GOOD
-
Have a short and precise name or identifier
Eg. "Feedback button on report page" -
Then add details:
-
Whose problem is solved by this story?
-
What problem is addressed in the story?
-
Why to do that? What is the value?
-
-
One template:
“As a <particular class of user>, I want to <be able to perform/do something> so that <I get some form of value or benefit>”
USER STORY
HOW TO WRITE A GOOD
-
It has clear acceptance criteria
-
Precise, reproducable steps how to check the completeness of the story
-
Understandable and possible checkable by the PM
-
EPIC
PROBLEM 1
TECHNICAL TASK
EPIC
PROBLEM 1
TECHNICAL TASK
-
Implementation steps
-
Sometimes technical details
-
Guide the development
-
Usually not interesting for the PM
-
Make it clear to everyone how to implement the story
-
Not too detailed, no need for code snippets
AT THE END OF THE ITERATION PLANNING
-
We have a good estimation what will fit into the iteration / sprint, it's not a commitment but we do our best and learn if we failed to deliver
-
We know what we will demo
-
Everyone understands the stories so anyone can grab any story and start working on that
NOW IT'S YOUR TURN!
