Agile planning and requirements estimation

1. Agile Planning and
Requirements
http://flic.kr/p/5wDp8h
Part 1

2. Recall: Iterative development process
Each time around the loop is an iteration
Iterations are timeboxed
http://en.wikipedia.org/wiki/File:Iterative_development_model_V2.jpg

3. Recall: Iterative development process
Each time around the loop is an iteration
Iterations are timeboxed
http://en.wikipedia.org/wiki/File:Iterative_development_model_V2.jpg

4. XP planning practice: User stories
“Plan using units of customer-visible functionality.”
http://flic.kr/p/884GBP

5. http://flic.kr/p/5dfuqL
User Story Activity
• You read user story excerpt from Beck (2005).
• I give you two random user stories for the following
proposed system.
• You write two of your own.
Proposed system:
Enables a person, upon his/her death, to
automatically share messages and data with
selected individuals.

6. Now, let’s watch these videos:
http://youtu.be/RkHxxuLx-NM
http://youtu.be/DaqyLWOEObY
User Story Activity (cont’d)
http://flic.kr/p/5dfuqL

7. Video Notes
• USs allow team to deliver increment of value
• Template: “As a <who>, I want <what> <why>.”
– Can be rearranged as long as it includes who, what, why
• Example: “As a dog, I want to order food online, so I
don’t have to rely on people anymore.”
• Goal: Tell a compelling story
• Don’t be afraid to have multiple whos, each with
their own why
• USs should not talk about the how

8. http://flic.kr/p/5dfuqL
User Story Activity (cont’d)
• You revise your user stories based on the video
– Both yours and the ones I gave you
• We discuss what changes you made and why

9. Some addition US principles
• Not written in stone
– Revision is acceptable and expected
• Fuzzy
– Further communication is usually needed
• Minimalist
– If you add stuff that the customer doesn’t want, then the
system will surely cost too much.
• Backed up by acceptance tests
– Will discuss further in next lectures

10. One possible way to collect user stories
from a customer
• Start from a starting point
• Let the customer walk through the vision
• Customer may have “artifacts” illustrating vision
• Chunk the vision into user stories
• Ask questions to clarify
• Don’t invent stories; let the customer “drive”
• Remind the customer that he can add more stories
later

11. OK. Now you have some user stories,
so what’s next?
For an answer, read the Weekly Cycle excerpt
from Beck (2005).
http://flic.kr/p/9ksxQa

12. OK. Now you have some user stories,
so what’s next?
http://flic.kr/p/9ksxQa
Answer in a nutshell:
Estimate how much work each US will be and
choose some to build in the next iteration

13. Agile estimation practice: Planning poker
Let’s watch this video to find out
what planning poker is all about:
http://youtu.be/0FbnCWWg_NY
But first, a quick word about…

14. The nebulous unit of work
• A unit is defined in terms of how much work you can
get done in the next iteration
• To start with, typically defined as something like
1/20th of what the team can accomplish
• This is after taking into account the fact that all
programming occurs in pairs.
– So an 8-person team has 4 pairs, each of which might be
able to get 5 “units” done this week.
– Better programmers might be able to do more “units” per
week.

15. http://flic.kr/p/5dfuqL
Planning poker activity
• Get together with your teammates
• Pool and sort your USs so you have a complete set
• Play planning poker for each US
• At the end, we’ll compare outcomes and consider
some questions

16. Some additional estimation principles
• Engineers give honest estimates that customers can
trust.
• Engineers refine estimates; customers refine
expectations.
• It is expected that you will work at a sustainable
pace.
– No heroes, no all-nighters, no super-human feats
– Either you get the code done like a human being, or you
don’t