Applied Software Project Management

1. Applied Software Project Management Estimation http://www.stellman-greene.com

2. What is estimation? • The project manager must set expectations about the time required to complete the software among the stakeholders, the team, and the organization’s management. • If those expectations are not realistic from the beginning of the project, the stakeholders will not trust the team or the project manager. http://www.stellman-greene.com

3. Elements of a Sound Estimate • To generate a sound estimate, a project manager must have: • A work breakdown structure (WBS) (A detailed specs helps you to do that)or a list of tasks which, if completed, will produce the final product • An effort estimate for each task • A list of assumptions which were necessary for making the estimate • Consensus among the project team that the estimate is accurate http://www.stellman-greene.com

4. Assumptions Make Estimates More Accurate • Team members make assumptions about the work to be done in order to deal with incomplete information • Any time an estimate must be based on a decision that has not yet been made, team members can assume the answer for the sake of the estimate • Assumptions must be written down so that if they prove to be incorrect and cause the estimate to be inaccurate, everyone understands what happened • Assumptions bring the team together very early on in the project so they can make progress on important decisions that will affect development http://www.stellman-greene.com

5. Wideband Delphi • Wideband Delphi is a process that a team can use to generate an estimate • The project manager chooses an estimation team, and gains consensus among that team on the results • Wideband Delphi is a repeatable estimation process because it consists of a straightforward set of steps that can be performed the same way each time http://www.stellman-greene.com

6. The Wideband Delphi Process • Step 1: Choose the team • The project manager selects the estimation team and a moderator. The team should consist of 3 to 7 project team members. • The moderator should be familiar with the Delphi process, but should not have a stake in the outcome of the session if possible. • If possible, the project manager should not be the moderator because he should ideally be part of the estimation team. http://www.stellman-greene.com

7. The Wideband Delphi Process • Step 2: Kickoff Meeting • The project manager must make sure that each team member understands the Delphi process, has read the vision and scope document and any other documentation, and is familiar with the project background and needs. • The team brainstorms and writes down assumptions. • The team generates a WBS with 10-20 tasks. • The team agrees on a unit of estimation. http://www.stellman-greene.com

8. The Wideband Delphi Process • Step 3: Individual Preparation • Each team member independently generates a set of preparation results. • For each task, the team member writes down an estimate for the effort required to complete the task, and any additional assumptions he needed to make in order to generate the estimate. http://www.stellman-greene.com

9. The Wideband Delphi Process • Step 4: Estimation Session • During the estimation session, the team comes to a consensus on the effort required for each task in the WBS. • Each team member fills out an estimation form which contains his estimates. • The rest of the estimation session is divided into rounds during which each estimation team member revises her estimates based on a group discussion. Individual numbers are not dicsussed. http://www.stellman-greene.com

10. The Wideband Delphi Process • Step 4: Estimation Session (continued) • The moderator collects the estimation forms and plots the sum of the effort from each form on a line: http://www.stellman-greene.com

11. The Wideband Delphi Process • Step 4: Estimation Session (continued) • The team resolves any issues or disagreements that are brought up. • Individual estimate times are not discussed. These disagreements are usually about the tasks themselves. Disagreements are often resolved by adding assumptions. • The estimators all revise their individual estimates. The moderator updates the plot with the new total: http://www.stellman-greene.com

12. The Wideband Delphi Process • Step 4: Estimation Session (continued): • The moderator leads the team through several rounds of estimates to gain consensus on the estimates. The estimation session continues until the estimates converge or the team is unwilling to revise estimates. • Step 5: Assemble Tasks • The project manager works with the team to collect the estimates from the team members at the end of the meeting and compiles the final task list, estimates and assumptions. • Step 6: Review Results • The project manager reviews the final task list with the estimation team. http://www.stellman-greene.com

13. Other Estimation Techniques • PROBE, or Proxy Based Estimating • PROBE is based on the idea that if an engineer is building a component similar to one he built previously, then it will take about the same effort as it did in the past. • Individual engineers use a database to maintain a history of the effort they have put into their past projects. • A formula based on linear regression is used to calculate the estimate for each task from this history. • COCOMO II • In Constructive Cost Model, or COCOMO, projects are summarized using a set of variables that must be provided as input for a model that is based on the results of a large number of projects across the industry. • The output of the model is a set of size and effort estimates that can be developed into a project schedule. http://www.stellman-greene.com

14. Other Estimation Techniques • The Planning Game • The Planning Game is the software project planning method from Extreme Programming (XP), a lightweight development methodology developed by Kent Beck in the 1990s at Chrysler. • It is a full planning process that combines estimation with identifying the scope of the project and the tasks required to complete the software. • The Planning Game is highly iterative. The scope is established by having Development and Business work together to interactively write “user stories” written on index cards to describe the scope. Each story is given an estimate of 1, 2 or 3 weeks. This process is repeated continuously throughout the project. http://www.stellman-greene.com

15. Conflicts • Developers always prefer higher estimate • Managers always prefer quick delivery • How to avoid the conflicts? • KISS (work the estimates with the developers)

16. Padded estimate generate distrust • Be aware • Software engineering often overoptimistic by nature • When no deep thinking is done, it is easy to ignore problems that may come up later • It is very tempting to make padded estimate since they lead to longer schedule and less pressure

17. Planning poker • Planning Poker is a consensus-based estimation technique for estimating, mostly used to estimate effort or relative size of tasks in software development. It is a variation of the Wideband Delphi method. It is most commonly used in agile software development, in particular the Extreme Programmingmethodology. • The method was first described by James Grenning[1] in 2002 and later popularized by Mike Cohn in the book Agile Estimating and Planning[2].

18. Planning poker card • A typical deck has cards showing the Fibonacci sequence including a zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; other decks use similar progressions.

19. Procedure • At the estimation meeting, each estimator is given one deck of the cards. All decks have identical sets of cards in them. • The meeting proceeds as follows: • A Moderator, who will not play, chairs the meeting, supported and advised by the Project Manager. • The most knowledgeable developer for a given feature provides a short overview. The team is given an opportunity to ask questions and discuss to clarify assumptions and risks. A summary of the discussion is recorded by the Project Manager. • Each individual lays a card face down representing their estimate. Units used vary - they can be days duration, ideal days or story points. During discussion, numbers must not be mentioned at all in relation to feature size to avoid anchoring. • Everyone calls their cards simultaneously by turning them over. • People with high estimates and low estimates are given a soap box to offer their justification for their estimate and then discussion continues. • Repeat the estimation process until a consensus is reached. The developer who was likely to own the deliverable has a large portion of the "consensus vote", although the Moderator can negotiate the consensus. • An egg timer is used to ensure that discussion is structured; the Moderator or the Project Manager may at any point turn over the egg timer and when it runs out all discussion must cease and another round of poker is played. The structure in the conversation is re-introduced by the soap boxes.

20. Avoid anchoring • Anchoringoccurs when a team openly discuss their estimates. A team normally has a mix of conservative and impulsive estimators and there may be people who have agendas; developers are likely to want as much time as they can have to do the job and the product owner or customer is likely to want it as quickly as possible.

21. Why anchor should be avoided? • The estimate becomes anchored when the product owner says something like, "I think this is an easy job, I can't see it taking longer than a couple of weeks", or when the developer says something like, "I think we need to be very careful, clearing up the issues we've had in the back end could take months". • Whoever starts the estimating conversation with, "I think it's 50 days" immediately has an impact on the thinking of the other team members; their estimates have been anchored, i.e. they are all now likely to make at least a subconscious reference to the number 50 in their own estimates. Those who were thinking 100 days are likely to reduce and those who thought 10 are likely to raise. This becomes a particular problem if the 50 is spoken by an influential member of the team when the rest of the team are predominantly thinking higher or lower. • Because the remainder of the team have been anchored they may consciously or otherwise fail to express their original unity; in fact they may fail to even discover that they were thinking the same thing. This can be dangerous, resulting in estimates that are influenced by agendas or individual opinions that are not focussed on getting the job done right.

22. Planning poker exposes the potentially influential team member as being isolated in his or her opinion among the group. It then demands that she or he argue the case against the prevailing opinion. If a group is able to express its unity in this manner they are more likely to have faith in their original estimates. If the influential person has a good case to argue everyone will see sense and follow, but at least the rest of the team won't have been anchored; instead they will have listened to reason.

23. 4 reasons why estimating is good for your project • For estimation, planning poker is by far the best mechanism we’ve used for estimation to date, and the accumulated estimates usually turns out quite realistic. • You’ll achieve sprint goals. History shows that we’re spending from one-third to twice the estimated time for each task(!) That does not sound all that great, but remember that these are the extremes. The most important, however, is that for the sum of tasks the estimates are usually quite accurate, which means that the sprint will be finished on-time, which is the goal of this procedure. • Discuss only the important. The mechanism for picking the right two people to discuss (the one with the low, and the one with the high estimate, if more than marginally different) leads to both efficient and effective resolution of the differences of opinion and understanding of a task. • Improves the specifications. Estimation reveals lacking task-specifications. When people are way off to either side in their estimates, the triggered discussion will resolve the weaknesses in the specification that caused different estimates, and the specification must be detailed accordingly. • The estimate tells you something about the task. Estimation adds another level of description to a task in and of itself. If a task “Create customer list for product X” is estimated at 1 hour, you know it’s not about developing a fancy application for it. Whipping up a text-file or installing a wiki might be the solution you’re looking for. Estimation is time-boxing and constraining the solution. Constraints yields creative and effective solutions.