Trail Length Are An Estimate of size,  while the time need to hike  is another story!

Trail length is an estimate of size, while the time need to hike it is another story!

More than occasionally I am asked, “Why should we size as part of estimation?”  In many cases the actual question is, “why can’t we just estimate hours?”  It is a good idea to size for many reasons, such as generating an estimate in a quantitative, repeatable process, but in the long run, sizing is all about the conversation it generates.

It is well established that size provides a major contribution to the cost of an engineering project.  In houses, bridges, planes, trains and automobiles the use of size as part of estimating cost and effort is a mature behavior. The common belief is that size can and does play a similar role in software. Estimation based on size (also known as parametric estimation) can be expressed as a function of size, complexity and capabilities.

E = f(size, complexity, capabilities)

In a parametric estimate these three factors are used to develop a set of equations that include a productivity rate, which is used to translate size into effort.

Size is a measure of the functionality that will be delivered by the project.  The bar for any project-level size measure is whether it can be known early in the project, whether it is predictive and whether the team can apply the metric consistently.  A popular physical measure is lines of code, function points are the most popular functional measure and story points are the most common relative measure of size.

Complexity refers to the technical complexity of the work being done and includes numerous properties of a project (examples of complexity could include code structure, math and logic structure).  Business problems with increased complexity generally require increased levels of effort to satisfy them.

Capabilities include the dimensions of skills, experience, processes, team structure and tools (estimation tools include a much broader list).  Variation in each capability influences the level of effort the project will require.

Parametric estimation is a top-down approach to generating a project estimate.  Planning exercises are then used to convert the effort estimate into a schedule and duration.  Planning is generally a bottom-up process driven by the identification of tasks, order of execution and specific staffing assignments.  Bottom-up planning can be fairly accurate and precise over short time horizons. Top-down estimation is generally easier than bottom-up estimation early in a project, while task-based planning makes sense in tactical, short-term scenarios. Examples of estimation and planning in an Agile project include iteration/sprint planning, which includes planning poker (sizing) and task planning (bottom-up plan).  A detailed schedule built from tasks in a waterfall project would be example of a bottom-up plan.  As most of us know, plans become less accurate as we push them further into the future even if they are done to the same level of precision. Size-based estimation provides a mechanism to predict the rough course of the project before release planning can be performed then again, as a tool to support and triangulate release planning.

The act of building a logical case for a function point count or participating in a planning poker session helps those that are doing an estimate to collect, organize and investigate the information that is known about a need or requirement.  As the data is collected, questions can be asked and conversations had which enrich understanding and knowledge.  The process of developing the understanding needed to estimate size provides a wide range of benefits ranging from simply a better understanding of requirements to a crisper understanding of risks.

A second reason for estimating size as a separate step in the process is that separating it out allows a discussion of velocity or productivity as a separate entity.  By fixing one part of the size, the complexity and capability equation, we gain greater focus on the other parts like team capabilities, processes, risks or changes that will affect velocity.  Greater focus leads to greater understanding, which leads to a better estimate.

A third reason for estimating size of the software project as part of the overall estimation process is that by isolating the size of the work when capabilities change or knowledge about the project increases, the estimate can more easily be re-scaled. In most projects that exist for more than a few months, understanding of the business problem, how to solve that problem and capabilities of the team increase while at the same time the perceived complexity[1] of the solution decreases. If a team has jumped from requirements or stories directly to an effort estimate  it will require more effort to re-estimate the remaining work because they will not be able to reuse previous estimate because the original rational will have change. When you have captured size re-estimation becomes a re-scaling exercise. Re-scaling is much closer to a math exercise (productivity x size) which saves time and energy.  At best, re-estimation is more time consuming and yields the same value.  The ability to re-scale will aid in sprint planning and in release planning. Why waste time when we should be focusing on delivering value?

Finally, why size?  In the words of David Herron, author and Vice President of Solution Services at the David Consulting Group, “Sizing is all about the conversation that it generates.”  Conversations create a crisper, deeper understanding of the requirements and the steps needed to satisfy the business need.  Determining the size of the project is a tool with which to focus a discussion as to whether requirements are understood.  If a requirement can’t be sized, you can’t know enough to actually fulfill it.  Planning poker is an example of a sizing conversation. I am always amazed at the richness of the information that is exposed during a group-planning poker session (please remember to take notes).  The conversation provides many of the nuances a story or requirement just can’t provide.

Estimates, by definition, are wrong.  The question is just how wrong.   The search for knowledge generated by the conversations needed to size a project provides the best platform for starting a project well.  That same knowledge provides the additional inputs needed to complete the size, complexity, capability equation in order to yield a project estimate.  If you are asked, “Why size?” it might be tempting to fire off the answer “Why not?” but in the end, I think you will change more minds by suggesting that it is all about the conversation after you have made the more quantitative arguments.

Check out an audio version of this essay as part of  SPaMCAST 201

[1] Perceived complexity is more important than actual complexity as what is perceived more directly drives behavior than actual complexity.


Climbing flight is a project, climbing them all is a program

Climbing flight is a project, climbing them all is a program.

Release planning generally focuses on the process needed to deliver functionality from projects. Projects are a central fixture of business, so it is easy to overlook program and portfolio release. Release planning for portfolios, programs and projects each has similarities and differences.

Project Level Release Plans: The project release plan describes what the team plans to deliver and when they intend to deliver.  These are a reflection of the team’s capability (reflected in the team’s velocity) and the product owner’s prioritization and strategy. An individual project’s release plan is very focused on the team’s ecosystem and generally has more a tactical orientation.  Project release plans are typically very granular, showing individual stories.

Program-Level Release Plans: Program release plans have to reflect a significantly larger number of moving parts than an individual project. The Project Management Institute (PMI) defines a program as a group of related projects, subprojects and program activities. Programs, because of their breadth, have more dependencies between projects and subprojects and will require more coordination, which impact both technical and business components. For example, earlier in my career I participated in a number of bank merger projects. Those projects were classic programs that included account conversions, application changes, signage/branding changes and business process changes. A change in the plan for one component could potentially cause a change in all of the rest of them. Also after a point the cutover date was nearly impossible to change. Developing a program release plan reflecting the needs and worries of a wide range of product owners is more than just assembling a view of all of the project release plans. Typically program-level release plans are less granular than project release plans showing the delivery of features and epics (collections of stories).

Portfolio-Level Release Plans: Portfolio management exists to help organizations maximize the impact of IT or project budget. In a perfect world, the portfolio of IT projects would be driven by the organization’s strategy and anticipated business value. Projects that are critical to business strategy and deliver the highest value would be prioritized, and then magically there would be capacity within the organization to tackle the project/program in the prioritized order. That magic is reflected in portfolio release plan. Portfolio release plans use inputs that include the organization’s strategy, estimates of business value and budgetary cost, the projected capacity AND technical capabilities to generate a plan that forecasts the evolution of the overall organization. A typical portfolio release plan will be at a high level showing product, programs and projects.

All three release plans are related. Project release plans influence program release plans and program release plans influence portfolio release plans. However, each release plan is not simply an aggregation from one level to the next. Project-level release plans are the most granular and are generally a reflection of the product owner’s needs and team performance.  Program-level release plans require negotiating the needs of multiple product owners, recognition of potential dependencies and reflect the performance of multiple teams. Portfolio release plans must integrate and balance organization level needs, capacities, capabilities and even politics. All three are important and having one does not lead linearly to the next.

Resources include the tools of the trade and every trade has tools.

Resources include the tools of the trade and every trade has tools.

The simple Measurement Readiness Checklist will be useful for any major measurement initiative, but is tailored toward beginning a measurement program.  The checklist will provide a platform for evaluating and discussing whether you have the resources, plans and organizational attitudes needed to implement a new measurement program or support the program you currently have in place.

I have divided the checklist into three categories: resources, plans, and attitudes.  Each can be leveraged separately. However, using the three components will help you to focus on the big picture. We will address each component separately over the next several days.

Here we continue the resources portion of the checklist:


Change costs money. Costs can include consultants, training, travel and an odd late-night pizza or two.

7 – A reasonable budget has been established and the implementation team can draw from the budget for planned expenditures.  Emergency funding can be attained to handle issues as they arise.

3 – A reasonable budget has been established and approved; however, access must be requested and justified for all expenditures.

1 – Any time that money is required funding must be requested and approved.

0 – Donations are sought in the organization’s lunchroom on a periodic basis (consider a PayPal donation button on your measurement team’s homepage).

Support Note:  Having the cash to support programs is just as important as having the cash to implement a measurement program.  Where the cash gets spent might be different for a support program.


Even if you have bales of cash, developing and implementing measurement processes will require effort. Effort will be required from many constituencies including the process-improvement team, management and from the teams being measured, just to name a few.

7 – A reasonable staffing plan has been established and the measurement program is the only project the assigned resources have been committed to.  Dedicated teams make sense for process improvement in software development.

4 – A reasonable staffing plan has been established and the measurement initiative is the highest priority for the assigned resources.

1 – All resources are matrixed to the measurement initiative and they are also assigned to other high priority projects.

0 – The program has access to all the effort needed after 5 PM and before 8 AM and during company holidays.

Support Note:  Dedicated resources might be more important for a program in support mode than even for an implementation project.  The issue is that we (us humans) tend to be distracted by new projects which means paying less attention to the projects in support mode.


Measurement requires having something to measure and then something to influence.  The organization needs to have a consistent flow of projects so that measurement becomes about the trends rather than about specific projects.

7 – Projects are constantly beginning and ending which will provide a platform for generating a continuous flow of information.

3 – There are numerous projects in the organization; however they typically begin early in the year and end late in the year or on some other periodic basis that makes data collection and reporting erratic.

1 – The organization does only a small number of projects every year making trending difficult.

0 – The organization only does one large project every year.

Support Note:  Like dedicated teams, access to projects to measure is really important to ongoing measurement programs.  Being able to continually generate reports and presentations on the data will help keep the interest stoked.

Calendar Time

Calendar time is a resource that is as important as any other resource. Severe calendar constraints can lead to irrational or bet-the-farm behaviors, which increase risk. This is especially true in big bang implementations (which is a strong reason to avoid such implementations).

7 – The schedule for implementing the measurement is in line with industry norms and includes time for tweaking the required processes before appraising.

3 – The schedule is realistic, but bare bones. Any problems could cause delay.

1 – Expectations have been set that will require a compressed schedule; however, delay will only be career limiting rather than a critical impact on the business.

0 – The measurement program implementation is critical for the organization’s survival and is required on an extremely compressed schedule.

Support Note:  If you are using the checklist to find areas to improve the support of your measurement program, I would drop this question.

Further Note: Also if you have rated this items a ‘0’ I would suggest that you have a very serious issue and should seek consulting support.

Next planning questions . . .

4-23 2013 puff pastry

The project is over, you’ve had the final retrospective and the team is beginning to think about what is next.  I have always that a celebration was an effective means of transitioning from one project to the next.  While the communal consumption of food as a team is a simple and powerful tool that should be part of your team-building toolkit, I have always found that stepping away from the ordinary pizza lunch and doing something a bit more out of the ordinary leaves a more  lasting impression. That lasting impression  can cement relationships and re-energize the team.

Many management pundits and social psychologists have remarked on the power of celebrating together. A simple twist I would like to suggest you occasionally try is the family potluck, each team member brings their favorite celebration dish.  One of my favorites is puff pastry wrapped brie with a cranberry reduction. A friend of mine is proud of his very special steamed dumplings filled with minced pork and red chilies (very spicy).  By including the team and their whole family we end up with cacophony of sights, tastes and noises, all of which helps create a deeper understanding of  who each person on your team really is.  I think we would all agree that our families or significant others are part of the broader team community.

Doing food as a team isn’t a new concept, but it never loses its luster. Take the next step and make your next celebration even better than the ordinary pizza lunch.

Post Thought Note:  It has been suggested that the word potluck  is code for the “boss is too cheap to buy me lunch.”  As leaders we nee to consider if that is our intent and if so we have a broader team problem a single project meal will fix.


Denial of a problem doesn’t resolve the problem. How many project status reports report a green status, right up until the day they suddenly are red? Recently I heard of project that was 80% complete for five years before having to be rescued. Both examples might be extreme, however they are not unique. Every time we close our eyes and deny some even minor fact in hope that it will go away, rather than tackling it head on, we postpone our day of reckoning.

In this lecture, Slaying The Dragon Within Us, Jordan Peterson says “if we don’t deal with our dragons they will continue to grow.” Covey says “act or be acted upon.” Projects usually don’t get in behind over night. It is easy to ignore the day here and the day there because it is easier than telling your sponsor or boss that you will be late however by delaying we may foreclose many of the good options for getting back on track. IN THE END both Peterson and Covey exhort us to tackle our problems before they get larger and easier to solve.

Note this may have posted earlier this week.