Local APLN member Edgardo Gonzalez, has kindly offered a Planning Poker card template for readers to download. (No longer are we tied to the decks generously given out by Mountain Goat Software at conferences; now we can print our own!) Based on the Fibonacci sequence, these cards print on standard Avery stationery and can be used by team members to estimate story points. (Post on Agile Estimation Techniques)
Thanks Edgardo for your gift to the community.
Last week I taught the “Agile Project Leadership” course with Sanjiv Augustine in Manchester, UK. The course went really well and we were looked after by Ian and Dot Tudor our hosts from TCC Training and Consultancy. They have a number of training facilities around the UK and ours was Aspen House, a converted church that retained all the arched doorways and high vaulted ceilings you would hope for.
It was a rare treat to teach in such nice surroundings and the church setting made evangelising agile all the more fun. In truth we were “preaching to the choir” as most of the delegates were already familiar with the benefits of agile and were looking for practical tools and more leadership techniques to move their organizations to the next level.
Continue reading "Agile Project Leadership and More on Accreditation" »
On February 4-5th I will be co-instructing with Sanjiv Augustine our new “Agile Project Leadership” training course in Manchester, UK. Sanjiv is the author of the excellent “Managing Agile Projects” book and fellow APLN board member.
This is a fast paced, practical focussed course that covers agile project management, leadership, and avoiding common agile project pitfalls.
You can find further details including a course outline at here.
I have written a few posts now on estimation and so I thought it was time for a summary. Also, I am planning to create a series of one page best practice summaries / cheat-sheets for agile and this seemed like a good candidate.
(I am a real fan of one-pagers; there is special value in getting everything visible and presented on one page that brings unique scope comprehension and clarity. Toyota and other lean organizations make heavy use of A3 reports, a one page summary of an issue, its root causes, countermeasures, and verification steps to summarize problems and planned solutions - they are powerful tools.
Incidentally, when I first started work I had a wise and cantankerous project manager who was full of oxymoronic proverbs. One I remember was “If you cannot summarize it on only one page, you need to go off and learn more about it!” An astute paradox.)
Anyway, here’s the summary; if you want more explanation on any of the points, refer to my previous posts (Upfront Estimates, Estimation Techniques, Estimate Ranges) on agile estimation.
Customer: How much is that parrot in the window?
Pet shop owner: Somewhere between $200 and $250
Customer: Erm, OK, I’ll give you $200 for it then!
To some people providing estimates as a range of values seem a strange and unsatisfying way of conducting business. They just want to know how much something will cost, not how much it may or not cost. This is reasonable if the object or service is ready for use, but not if it has yet to be created. The more uncertainty involved in the process the more likely there will be some variability. Now consider this conversation:
Customer: How much will it cost for a taxi ride from the library to the airport
Taxi driver: Probably between $20 and $25, depending on traffic
Customer: OK, that sounds fair, let’s go
It seems more reasonable, we understand the variability of traffic. Unfortunately not all stakeholders understand the variability caused by evolving requirements and changing technology often associated with software projects. However the uncertainties of software development are real and we have an obligation to report estimates as ranges to help manage expectations.
Continue reading "Software Estimates - Managing Expectations via Ranges" »
In the last post we covered the importance of engaging the right people in the estimation process and the need to use more than one estimation approach. Today we will look at some examples of team based estimation approaches and practical ways to combine estimate result sets.
Estimation approaches (agile or traditional) can be divided into Heuristic (expert judgment based) and Parametric (calculation based) approaches.
Heuristic
• Comparison to similar systems
• Expert Judgment
• Activity Based (top down)
• Task Based (bottom up)
Parametric
• Function Points
• Use Case Points
• Object Points
Both sets of approaches have some merit, but they are also have their limitations and are open to misuse and over reliance too. For instance Activity Based (top-down) estimating is the most commonly employed estimation approach, but has been found to be the least accurate. Capers Jones in his book “Estimating Software Costs” instead recommends task based (bottom up) estimating approaches that tend to yield better results by encouraging a more thorough investigation into the likely tasks.
Involving many stakeholders
We should ask the people who will be doing the work how long they think it will take. Not only are they closest to the technical details and therefore theoretically in a better position to create a better estimate, but also because of the psychological benefits also.
If someone just hands you an estimate for your work and tells you it should take two weeks, you can either comply and try to get it done in two weeks or rebel and either finish it early or explain why it will take much longer to illustrate the poor nature of the estimate. Even complying and doing the work in two weeks can be a problem; given two weeks work will expand to fill the time. If a solution is found early time will likely be spent finding a better solution or refining the existing one. We do not get enough of the early finishes to cancel out the late ones. As Don Reinertsen observes in “Managing the Design Factory” in engineering we get few early finishes.
Continue reading "Agile Estimating – Estimation Approaches" »
In September I will be co-instructing with Sanjiv Augustine the new course “Agile Project Leadership”. Sanjiv is a fellow APLN board member and author of the excellent “Managing Agile Projects” book. I’m really excited because a) we have an excellent course that will stretch attendees while engaging them, and b) co-teaching with Sanjiv will be a blast since he is such a knowledgable and personable expert.
Our first course offering will be in Manchester, UK on September 10-11th. You can find further details including a course outline at Agile University here
(Chop those large projects down to size)
When I started out as a PM and had a few successful projects under my belt, I wanted to manage larger and larger projects. Now I’m looking for ways to make them smaller and limit the functionality initially tackled. This is not just laziness or a lack of ambition on my behalf, instead it is a realization that delivering business value comes from successful projects and that large projects are inherently risky and more likely to fail.
Jim Johnson of the Standish Group presented some interesting metrics at the PMI Global Congress conference in Toronto a couple of years ago that confirmed my suspicion. From a study of over 23,000 projects it was found that the success rate dropped as project duration increased.
From the graph we can see that most (over 50%) of the 6 month projects surveyed were deemed successful, dropping to 23% of 12 month projects, and less than 10% of 24 month projects. Now, we need to understand what “Sucess” means here. The criteria was quite strict and defined as within 15% of cost and schedule and to customer defined functionality and quality standards.
I expect a large proportion of these “failed” projects merely missed the 15% cost or time criteria and the picture would not be so bad with a wider margin. Predicting costs over long periods is notoriously difficult as even labour rates and inflation predictions elude the best market ecconomists. However the trend is still true, larger projects carry a much higher probability of failure for a number of reasons we will see...
In my last post I suggested spending less time worrying about project metrics and more time on stakeholder concerns, so I thought a tool to simplify project tracking might be useful.
Having completed project estimating with the team, it is often necessary to convert effort estimates into cost estimates based on likely utilizations and then track actual hours billed against these projections. Today’s download is a simple burn-rate estimation tool that produces S-Curve graphs and let you track actual spend against burn-rate projections and planned budgets.
You can download the spreadsheet here:
Converting effort estimates into project durations and team sizes is an important part of project planning. How this is done varies from project manager to project manager, to some it is an art, others a science, and to many a case of living with everyday constraints. Today I will focus on the science and its implication to pair programming.
If your initial project estimates indicate 72 person months of effort how do you best resource it?
1 person for 72 months?
72 people for 1 month?
6 people for 12 months?
Intuitively we know that 1 person for 72 months might work (providing they had all the right skills) but typically business wants the benefits of a project as soon as possible. 72 people for 1 month is extremely unlikely to work, unless the project is simple and massively parallel, like cleaning oil off rocks on a beach. Usually adding more resources beyond an optimal level provides diminishing rates of return. As the old saying goes, “You can not make a baby in one month with nine women, (although it might be fun to try.)”. Also as Fredrick Brooks stated in, The Mythical Man Month ”Adding resources to a project that is already late will make it later”. So, given an effort estimate how do we determine the optimal team size and schedule to deliver quickly and keep costs down?
While adding team members to a project increases costs in a linear fashion, the project timeline is not reduced in a corresponding linear way. Research by Putnam Norden found that for projects that require communication and learning (like software projects), the effort to time curve follows a Rayleigh distribution. Putnam confirmed that this curved applied to software projects in his article “A General Empirical Solution to the Macro Software Sizing and Estimation problem”, IEEE Transactions of SW Engineering, July 1978 and the curve became known as the Putnam Norden Rayleigh curve or PNR Staffing curve as shown below.
Continue reading "Schedule Questions: Pair Programming and the PNR Curve" »
Q: Does Earned Value work for software projects?
A: Absolutely, Earned Value Analysis (EVA) is a statically valid reporting approach that can be applied to any endeavour. It compares actual progress and spend against projected progress and spend.
Q: Can you use Earned Value on Agile projects?
A: You can, but I would not recommend it. There are fundamental problems using EVA on agile projects relating to baseline plan quality. Also there are better alternatives available for agile projects.
Earned Value analysis and reporting measures conformance and performance to a baselined plan. So, given that on agile projects we know that our initial plans are likely to change, why track progress against a weak plan?
The next Calgary Agile Project Leadership Network (APLN) meeting on Thursday October 12th is full. However we are currently putting names on a wait list in case of cancellations, so if you would still like to attend this event send an email with your contact details to register@calgaryapln.org and we will see if we can get you in.
For those of you already signed up, I’m sure the presentation will be very interesting. Rob Morris from CDL Systems will be talking about “Estimating and Planning Agile projects” and I had a chance to review Rob’s material earlier this week. It looks really good and draws from Rob’s deep experience along with materials from Mike Cohn and Steve McConnell.
Event: Calgary APLN: “Agile Estimation and Planning”
Presenter: Rob Morris, Principle Software Engineer, CDL Systems
Date: Thursday October 12, 2006
Time: 12:00 PM – 1:00 PM (registration will commence at 11:30 AM)
Light beverages to be provided
Location: 5th Avenue Place – Conference Room
Suite 202, 420 – 2nd Street SW
Topic: “Agile Estimation and Planning”
Rob’s presentation will explore Agile estimation and how it can be used in determining what can be accomplished within an iteration and how to estimate multi-iteration release plans. He will also touch on firm fixed price estimation and compare these approaches with more traditional estimation approaches.
About the Speaker:
Rob is the principal software engineer at CDL Systems and has over 20 years experience developing software systems. His more recent work has involved overseeing the development of control station software used to fly unmanned aerial vehicles currently operating in Iraq and Afghanistan. Rob has a BSc. in Electrical Engineering and Masters degrees in Computer Science and Software Engineering. He has embraced Agile techniques and tries to shoehorn them into the more document centric military projects at every opportunity. He is also a certified ScrumMaster.
The next Calgary Agile Project Leadership Network (APLN) meeting will be on Thursday October 12th when Rob Morris from CDL Systems will be talking about “Estimating and Planning Agile projects”. Here are the details:
Event: Calgary APLN: “Agile Estimation and Planning”
Presenter: Rob Morris, Principle Software Engineer, CDL Software
Date: Thursday October 12, 2006
Time: 12:00 PM – 1:00 PM (registration will commence at 11:30 AM)
Light beverages to be provided
Location: 5th Avenue Place – Conference Room
Suite 202, 420 – 2nd Street SW
Topic: “Agile Estimation and Planning”
Rob’s presentation will explore Agile estimation and how it can be used in determining what can be accomplished within an iteration and how to estimate multi-iteration release plans. He will also touch on firm fixed price estimation and compare these approaches with more traditional estimation approaches.
About the Speaker:
Rob is the principal software engineer at CDL Systems and has over 20 years experience developing software systems. His more recent work has involved overseeing the development of control station software used to fly unmanned aerial vehicles currently operating in Iraq and Afghanistan. Rob has a BSc. in Electrical Engineering and Masters degrees in Computer Science and Software Engineering. He has embraced Agile techniques and tries to shoehorn them into the more document centric military projects at every opportunity. He is also a certified ScrumMaster.
To register for this event and for more information about the Calgary APLN group visit www.calgaryapln.org
