Chapter 3- Project Planning

1
Agenda
• Scope the problem

• Add More People

• Managing Customers

• Burn Down Chart

• The Big Board

• Standup Meeting

2
Great Software Delivers

3
4
Project Planning

What to do if your estimate is too big?

5
 Solution - Scope the problem

6
Project Planning
• What to do?
• Scope the problem
• Focus on most critical functionality and see if customer is
willing to focus on that subset

• In general, “scope the problems” means drop features until the

remaining features can be completed by the original due date

• Who does the scoping?

• The customer

7
Milestone 1.0
• In particular, we are attempting to define what features
will go into “milestone 1.0”

• Milestone 1.0 == first major release to the customer

• In iterations, you show software for feedback but do
not generally deploy the software for production use
• With milestones, you are delivering software that
will go into production use

8
Milestone 1.0 Do’s and Don’ts
• Do balance functionality with customer impatience
• Help customer understand what can be done before the
deadline
• Help them understand that features are being delayed not
dropped
• Don’t get caught planning nice-to-haves
• You need to focus on what’s needed: mission critical fun.
• Don’t worry about length (yet)
• You’re trying to understand your customer’s priorities
9
Soundness Check
• Once you have identified the features that need to go
into Milestone 1.0, recheck your estimate
• In the book, since you have less features, the new estimate comes to
273 days (3/4 of a year)
• You still have 90 days to complete the work
• And we are assuming a team size of 1 person
• In this situation, we would be forced to reprioritize with
the customer and cut functionality to the bone
• OR…

10
11
What's the difference between a milestone and a
version?
 Not much.
 In fact, you could call your first milestone “version 1” if you like.
 Milestone marks a point at which you deliver significant software
and get paid by your customer, whereas a version is more of a
simple descriptive term that is used to identify a particular release of
your software.
 'Version' is a label and doesn't mean anything more, whereas "
Milestone " means you deliver significant functionally and you get
paid.

12
 Iteration

13
Iteration
• An iteration produces working software
• When you complete an iteration, you have something
to show the customer.
• Iterations should be relatively short; where “short” is
defined by the estimated length of the project.

• Each iteration is a mini life cycle or mini project

• A typical life cycle consists of these major activities
• Requirements; Design; Code; Test; Deploy
14
Iteration

15
16
 Solution - Add More People

17
Add More People
• We could add more people!
• Lets increase the team size to 3 people
• 273 / 3 = 91 days of work and we have 90 days left
• That should do the trick assuming a few sleepless nights as the deadline
approaches, right?
• WRONG!
• First, we have 90 calendar days, not 90 work days!
• Recall that we get roughly 20 works days per month
• So a team of 3 can accomplish roughly ((20*3)*3) 180 days worth of
work over 90 calendar days ASSUMING ALL GOES WELL

18
Add More People
• Second, you can’t assume that the customer won’t change
things on you as you move forward

• Third, you can’t assume that the two new developers will be
up to speed on the project and ready to put full productive work
days into the project on day one

• With three people, we now have

• two people to train and get ready to work on the project

• three communication paths to manage (previously zero)

19
Add More People

20
Add More People

21
Example
• With 3 developers, we start by assuming that they can produce
180 days of development effort
• You then negotiate with the customer until the estimate of all
the features in milestone 1.0 is less than 180 days
• You then create an iteration plan and get to work
• Keep your iterations short (30 calendar days, 20 work days)
• It helps you deal with change and keep you focused
• Keep your iterations balanced (new features, fixing bugs,
etc.)
22
And, now reality sets in
• We can’t necessarily assume 180 days of work from three
developers over three calendar months
• During the day there are constant interruptions that prevent
developers from remaining “in the flow”
• rather than 8 productive hours in a work day, you find that
you only achieve 5 hours (or less)
• To account for this, agile methods make use of a concept called
“team velocity” or “velocity”
• Velocity is a percentage: given X number of days, how much
of that time is productive? A default value is 0.7

23
Velocity

 The velocity of a team is a measure of how much work

that the team can handle within a specific time period, i.e.

how much of the product backlog can be completed by the

team in a sprint.

24
Realistic Estimate

 30 calendar days, 20 work days == 20 * 0.7 ==14

days of productive time !!!!

25
Realistic Estimate

26
27
 Solution - Managing Customers

28
Managing Customers
• The customer will probably definitely not like the change
from 273 days of work possible to 126
• Since it means a big reduction in what can be
accomplished

29
Managing Customers
• What to do?
• Add an iteration (if they will let you)
• Explain that overflow work is not lost, just
postponed
• Be transparent about how you came up with your
figures
• You now have an estimate that you can be
confident in
30
User Stories and Tasks

31
User Stories and Tasks
• Each user story needs to be split into tasks

• Each task then needs an estimate associated with it

• The entire team should participate in breaking a user story

into tasks; planning poker should be used to assign
estimates

• Example User Story: Create a Date in the System (

Estimate: 13 days)

32
User Stories and Tasks
• Tasks:
• Create a date class that contains events: 3 days
• Create user interface to create, view and edit a date: 5
days
• Create the schema for storing dates in a database: 3 days
• Create SQL scripts for adding/finding/updating dates: 2
days
• Total Task Time: 13 days! (Recommend, do estimation
on tasks)
33
 Summary

34
Project Planning

What to do if your estimate is too big?

35
36
37
38
 Exercises

39
40
 A development team at X, Inc. is creating a new operating
system for the company's best-selling smartphone, iX.
 The work is split into two-week long sprints.
 It has been estimated that 4 sprints, or 8 weeks of effort, are
required before the first version of the operational system will
be ready for releasing to customers.
 There are three people on the team. With each team member
producing 6 hours of effort daily.
 What is the total time for the release?
41
 The total ideal effort per week i= 3 x (6*5) = 90 hours.

 Long sprint = 2 * 90, This equals 180 hours per two-week

long sprint

 720 hours for the release

42
 Burn Down Chart

43
Burn Down Chart
• gives us a specific action item whenever an estimate changes or
work gets done

44
A burndown chart typically includes:
• X-axis (horizontal axis): The X-axis is the horizontal axis and
represents the amount of time left to complete the project. This is
usually shown in days.
• Y-axis (vertical axis): The Y-axis is the vertical axis and represents
the remaining effort needed to complete the project.
• Actual work line: The actual work line represents the actual work
remaining. This is often different from the initial estimate as issues
arise and the time it takes to complete work grows. The actual work
line might be straight in some cases, but tends to be a less linear path
due to project issues and un-forecasted work.
• Ideal work remaining line (estimated work): The ideal work
remaining line represents the amount of work you estimated in an
ideal scenario. This is often a more straight trajectory compared to
the actual work line.
45
Burn Down Chart

46
Burn Down Chart

47
 The Big Board

48
The Big Board
• Once you have a realistic estimate and an iteration plan based on
that estimate, you are ready to get started
• You will track your progress with a software development
dashboard
• A large whiteboard that is partitioned to help your team focus on
what is happening during the current iteration
• It is updated at least once per day during the stand up meeting but
could be useful to update it more often than that.
• It is a one-stop shop for getting a “big picture” view of the current
iteration
49
The Big Board

50
The Big Board

51
The Big Board

52
The Big Board

53
The Big Board

54
The Big Board

55
The Big Board

56
The Big Board

57
The Big Board

58
The Big Board

59
The Big Board

60
The Big Board

61
 Standup Meeting

62
Standup Meeting
• A daily meeting used to
• keep the team motivated and aware of progress
• keep your board up-to-date
• highlight problems early

63
Standup Meeting
• It should
• Track progress, update burn-down rate, update
tasks,
• discuss what happened yesterday and plan today’s
activities,
• bring up issues, and last between 5 and 15 minutes

• “Its so short, no one has time to sit down”

64
 Tasks

65
 Split user story into tasks

 Draw your Burn Down Chart

 Design your big board

66