1. Iterative Planning

2. What are you going to learn about today?
Agile planning practices
Simple estimation technique
Simple practice for tracking progress

3. Recall: Iterative development process
We are here
Note that planning and requirements don’t necessarily happen one right after the other

4. For those following along in the book…
For those following along in the book…
Larman doesn’t really cover practical planning, so I’m going to draw from some other sources

5. OK. So you have some UCs, What’s next
OK. So you have some UCs, What’s next? For an answer, read the excerpt “Weekly Cycle” from Beck (2005).

6. OK. So you have some UCs, What’s next?
In a nutshell: Estimate how much work each UC will be and choose some to build in the next iteration

7. Agile estimation practice: Planning poker
Let’s watch this video to find out what planning poker is all about:
But first, a quick word about…

8. 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 programming might occur in pairs
So an 8-person team might have 4 pairs, each of which might be able to get 5 units done
Some team members might be able to do more units than others

9. OK. Now let’s watch the video:

10. Recap: Estimation with planning poker
Based on the “wisdom of the crowd”
Idea: More opinions produce better accuracy
Cards with units of work: 1, 3, 5, 8, 13, 20, 40
Assume that 20 units is what the whole team can do in a single iteration
Rules: For each UC…
Discuss work involved
Flip cards
Repeat until consensus
Efficiency in estimating is important
Don’t expect your estimates to be super accurate

11. Why do estimation as a card game?

12. Why do estimation as a card game?
Everyone’s opinion is important. Having everyone flip cards at the same time assures that everyone’s opinion is on the table.

13. How do you use these rough estimates?

14. How do you use these rough estimates?
Provide client an idea of the cost of implementing each UC
He/she already knows the value
Then, the client can prioritize
Based on the prioritization, you break the UCs into tasks and assign the work
May involve more detailed estimates on a few UCs/tasks

15. Why is efficiency in planning poker important?

16. Why is efficiency in planning poker important?
Even with the wisdom of the crowd, your estimates still won’t be super precise
No sense wasting a lot of time on estimation

17. 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

18. Activity for next class(?): Planning poker
Activity for next class(?): Planning poker
Get together with your teammates
Pool and sort your UCs so you have a complete set
Play planning poker for each UC
At the end, we’ll compare outcomes and consider some questions

19. Another agile practice: Informative workspace
Read the handout (Beck 2005), and we will discuss (esp. what we can do in this course)

20. Popular practice: Kanban board

21. Here’s another example…

22. And another…

23. How do you think we should approximate an informative workspace in this course?

24. Activity for next Wednesday: Planning an iteration
Activity for next Wednesday: Planning an iteration
I will prioritize your UCs
See how many of the UCs your team can do in an iteration, favoring higher priority UCs over lower
For each UC that your team will do, break it into subtasks
Assign each subtask to a person and give a time estimate in hours
Use informal visual/spatial layout tricks to capture dependencies

25. Summary Estimation with planning poker Informative workspaces
Summary
Estimation with planning poker
Informative workspaces
Progress tracking with Kanban boards