Agile reminds us that the focus of any set of requirements needs to be on an outcome rather than a collection of whats and whos.  Storytelling is a powerful tool to elevate even the most diehard requirements analyst from a discussion of individual requirements to a discussion of outcomes. The onion metaphor that is popularly used in agile planning (Cohn’s Planning Onion) can be used to describe the evolution of backlogs. Building an initial backlog is much like peeling through the layers of an onion to get to the core. There are many mechanisms for developing and maintaining the detailed backlogs, including: asking, observing, showing and all sorts of hybrids. Using the onion metaphor, the techniques we have explored in the past are the second layer of the onion. However, before getting to the center of the backlog evolution onion, composed of features, epics, and user stories, we need to understand the big picture.  Structured storytelling is effective tool to elicit a description of an outcome and nuances behinds that description, the outer layer in the backlog onion. The outside layer of the backlog evolution onion provides a strategic vision used for budgeting, change management and to provide context to guide the team or teams of teams as the development process progresses. (more…)

The Mythical Man-Month

The Mythical Man-Month

In the seventh essay of The Mythical Man-Month, Fred P. Brooks begins to tackle the concept of estimating. While there are many estimating techniques, Brooks’ approach is a history/data-based approach, which we would understand as today as parametric estimation. Parametric estimation is generally a technique that generates a prediction of the effort needed to deliver a project based on historical data of productivity, staffing and quality. Estimating is not a straightforward extrapolation of has happened in the past to what will happen in the future, and mistaking it as such is fraught with potential issues. Brooks identified two potentially significant estimating errors that can occur when you use the past to predict the future without interpretation.

Often the only data available is the information about one part of the project’s life cycle. The first issue Brooks identified was that you cannot estimate the entire job or project by just estimating the coding and inferring the rest. There are many variables that might affect the relationship between development and testing. For example, some changes can impact more of the code than others, requiring more or less regression testing. The link between the effort required to deliver different types of work is not linear. The ability to estimate based on history requires a knowledge of project specific practices and attributes including competency, complexity and technical constraints.

Not all projects are the same. The second issue Brooks identified was that one type of project is not applicable for predicting another. Brooks used the differences between small projects and programming systems products to illustrate his point. Each type of work requires different activities, not just scaled up versions of the same tasks. Similarly, consider the differences in the tasks and activities required for building a smart phone app compared to building a large data warehouse application. Simply put, they are radically different. Brooks drove the point home using the analogy of extrapolating the record time for 100-yard dash (9.07 seconds according to Wikipedia) to the time to run a mile. The linear extrapolation would mean that a mile could be run in 2.40 (ish) minutes (a mile is 1760 yards) the current record is 3.43.13.

A significant portion of this essay is a review of a number of studies that illustrated the relationship between work done and the estimate. Brooks used these studies to highlight different factors that could impact the ability to extrapolate what has happened in the past to an estimate of the future (note: I infer from the descriptions that these studies dealt with the issue of completeness and relevance. The surveys, listed by  the person that generated the data, and the conclusions we can draw from an understanding of the data included:

  1. Charles Portman’s Data – Slippages occurred primarily because only half the time available was productive. Unrelated jobs meetings, paperwork, downtime, vacations and other non-productive tasks used the remainder.
  2. Joel Aron’s Data – Productivity was negatively related to the number of interactions among programmers. As the number of interactions goes up, productivity goes down.
  3. John Harr’s Data- The variation between estimates and actuals tend to be affected by the size of workgroups, length of time and number of modules. Complexity of the program being worked on could also be a contributor.
  4. OS/360 Data- Confirmed the striking differences in productivity driven by the complexity and difficulty of the task.
  5. Corbatoó’s Data – Programming languages affect productivity. Higher-level languages are more productive. Said a little differently, writing a function in Ruby on Rails requires less time than writing the same function in macro assembler language.

I believe that the surveys and data discussed are less important that the statistical recognition that there are many factors that must be addressed when trying to predict the future. In the end, estimation requires relevant historical data regardless of method, but the data must be relevant. Relevance is short hand for accounting for the factors that affect the type work you are doing. In homogeneous environments, complexity and language may not be as big a determinant of productivity as the number of interactions driven by team size or the amount of non-productive time teams have to absorb. The problem with historical data is that gathering the data requires effort, time and/or money.  The need to expend resources to generate, collect or purchase historical data is often used as a bugaboo to resist collecting the data and as a tool to avoid using parametric or historical estimating techniques.

Recognize that the the term historical data should not scare you away.  Historical data can be as simple as a Scrum team collecting their velocity or productivity every sprint and using it to calculate an average for planning and estimating. Historical data can be as complex as a pallet of information including project effort, size, duration, team capabilities and project context.

Previous installments of the Re-read of The Mythical Man-Month

Introductions and The Tar Pit

The Mythical Man-Month (The Essay)

The Surgical Team

Aristocracy, Democracy and System Design

The Second-System Effect

Passing the Word

Why did the Tower of Babel fall?


There are many levels of estimation including budgeting, high-level estimation and task planning (detailed estimation).  We can link a more classic view of estimation to  the Agile planning onion popularized by Mike Cohn.   In the Agile planning onion, strategic planning is on the outside of the onion and the planning that occurs in the daily sprint meetings at the core of the onion. Each layer closer to the core relates more to the day-to-day activity of a team. The #NoEstimates movement eschew developing story- or task-level estimates and sometimes at higher levels of estimation. As you get closer to the core of the planning onion the case for the #NoEstimates becomes more compelling.

03fig01.jpg (500×393)

Planning Onion


Budgeting is a strategic form of estimation that most corporate and governmental entities perform.  Budgeting relates to the strategy and portfolio layers of the planning onion.  #NoEstimates techniques doesn’t answer the central questions most organizations need to answer at this level which include:

1.     How much money should I allocate for software development, enhancements and maintenance?

2.     Which projects or products should we fund?

3.     Which projects will return the greatest amount of value?

Budgets are often educated guesses that provide some approximation of the size and cost of the work on the overall backlog. Budgeting provides the basis to allocate resources in environments where demand outstrips capacity. Other than in the most extreme form of #NoEstimate, which eschews all estimates, budgeting is almost always performed.

High-level estimation, performed in the product and release layers of the planning onion, is generally used to forecast when functionality will be available. Release plans and product road maps are types of forecasts that are used to convey when products and functions will be available. These types of estimates can easily be built if teams have a track record of delivering value on a regular basis. #NoEstimates can be applied at this level of planning and estimation by substituting the predictable completion of work items for developing effort estimates.  #NoEstimates at this level of planning can be used only IF  conditions that facilitate predictable delivery flow are met. Conditions include:

  1. Stable teams
  2. Adoption of an Agile mindset (at both the team and organizational levels)
  3. A backlog of well-groomed stories

Organizations that meet these criteria can answer the classic project/release questions of when, what and how much based on the predictable delivery rates of #NoEstimate teams (assuming some level of maturity – newly formed teams are never predictable). High level estimate is closer to the day-to-day operations of the team and connect budgeting to the lowest level of planning in the planning onion.

In the standard corporate environment, task-level estimation (typically performed at the iteration and daily planning layers of the onion) is an artifact of project management controls or partial adoptions of Agile concepts. Estimating tasks is often mandated in organizations that allocate individual teams to multiple projects at the same time. The effort estimates are used to enable the organization to allocate slices of time to projects. Stable Agile teams that are allowed to focus one project at a time and use #NoEstimate techniques have no reason to estimate effort at a task level due to their ability to consistently say what they will do and then deliver on their commitments. Ceasing task-level estimation and planning is the core change all proponents of #NoEstimates are suggesting.

A special estimation case that needs to be considered is that of commercial or contractual work. These arrangements are often represent lower trust relationships or projects that are perceived to be high risk. The legal contracts agreed upon by both parties often stipulate the answers to the what, when and how much question before the project starts. Due to the risk the contract creates both parties must do their best to predict/estimate the future before signing the agreement. Raja Bavani, Senior Director at Cognizant Technology Solutions suggested in a recent conversation, that he thought that, “#NoEstimates was a non-starter in a contractual environment due the financial risk both parties accept when signing a contract.”

Estimation is a form of planning, and planning is a considered an important competency in most business environments. Planning activities abound whether planning the corporate picnic to planning the acquisition and implementation of a new customer relationship management system. Most planning activities center on answering a few very basic questions. When with will “it” be done? How much will “it” cost? What is “it” that I will actually get? As an organization or team progresses through the planning onion, the need for effort and cost estimation lessens in most cases. #NoEstimation does not remove the need for all types of estimates. Most organizations will always need to estimate in order to budget. Organizations that have stable teams, adopted the Agile mindset and have a well-groomed backlog will be able to use predictable flow to forecast rather than effort and cost estimation. At a sprint or day-to-day level Agile teams that predictably deliver value can embrace the idea of #NoEstimate while answering the basic questions based what, when and how much based on performance.


A framework is just a framework without planning!

A framework is just a framework without planning!

Personal Scrumban establishes a framework for conquering the chaos that day-to-day life can throw at you. However having a structure, even a structure with multiple classes of service, does not get the most important pieces of work in the queue when they need to be in the queue. Planning is required. Weekly and daily planning exercises, similar to sprint planning and the daily stand-up, are useful for taming the backlog and adapting to the demands of real life.

I begin all weekly planning sessions with a quick backlog grooming session (note: when new items are added to the queue during the week, grooming can be performed). In personal Scrumban, the goal of backlog grooming is not get team consensus (no need for the Three Amigos). Rather the goal is to ensure each backlog item that might need to be tackled in the next week has been broken down so that there are one or two immediate next steps identified. The first step in backlog grooming is to ensure that all work items (or stories) have been classified by class of service. For example, if one of the work items was “Review cover art for the Hand-Drawn Slide Saturday Ebook,” the work item should be classified in the Podcast/Blog class of service. Classes of service act as a macro prioritization and assigns the work to the relevant time slice in any given day. The second step is sizing, just like in Scrum, the immediate next steps should be of a size that can be accomplished in a single sitting. The information gathered in execution will used as part of daily planning or during the next weekly planning session.

Weekly planning is comprised of getting work items in priority order and then deciding which needs to be dealt with during the upcoming week GIVEN what is known when planning occurs. If you have not already established a work-in-process limit (WIP), set one for each class of service. A WIP limit is the amount of work you will allow yourself to start and actively work on at any point. Work is only started if there is capacity to complete the task. Prioritize up to the WIP limit or just slightly past the limit in each category. Remember if as you complete tasks in a category (and you have time) you can refresh the backlog by prioritizing new items. I generally do my weekly planning every Sunday evening so that I am ready to begin the when I roll out of bed on Monday.

Daily planning is exactly like a daily stand-up meeting, with two minor twists. In Scrum, the daily stand-up meeting starts the day with each team member answering the three famous questions:

  • What did I complete since the last meeting?
  • What will I complete before the next meeting? and
  • What is blocking progress?

The three questions provide a framework to make generate laser focus on what is done and what needs to be done. The twists

In personal Scrumban, as in normal Kanban, completed work items would have been moved to the completed column of the Kanban board as soon as they done, however this is a good time to ensure that has occurred. The twists relate to how new items are dealt with and time allocation. During planning, work items that will be accomplished during the next 24 hours should be moved to in-progress. Given the nature of daily planning, if new work items have been discovered and prioritized into the backlog, they then become part of the standard planning process. The stand-up also provides time to reflect on anything that will block accomplishing the planned work items. A second twist to the stand-up process is a reassessment of the time slices being provided to each class of work. For example, if a critical work product needs to be completed, time from a more discretionary class of service can be reallocated and the work items in this category can be put on hold.

A weekly planning session provides a stage to address the week. To paraphrase Helmuth von Moltke the Elder, no weekly plan stands first contact with Monday. The daily stand-up provides a platform to re-adjust to the nuances of the week so that you can stay focused on delivering the maximum value possible. Without planning, all personal Kanban is a framework and a backlog of to-do items.  Planning puts the energy into the framework that provides the guidance and reduces stress.


Forewarned is forearmed!

Forewarned is forearmed!

Testing is an important set of tools for influencing the quality of the functionality that gets delivered. The term testing can cover a wide range of activities ranging from reviews to user acceptance testing with a nearly infinite number of stops in between. Some organizations expend up to 60 – 70% of project effort just on testing (this is abnormally high), often with the intention of “testing in” quality. When the effectiveness and efficiency of testing has been derailed there are five typical root causes.

  • Planning
  • Involvement
  • Organizational Management
  • Capability
  • Process

Planning is the first of the root causes. Poor planning will yield poor results. Test planning defines the approach a project will use to verify and validate the deliverable they are creating. There are several inputs that impact and shape a test plan. The inputs are:

  1. Risk – Risk is a reflection of possibilities that might impact the project if they occur. Some projects will inherently have a bigger impact on the organization if things go wrong. Testing can be tuned to act as insurance that risks do not become issues. Agile projects use a wide range of techniques to incorporate risk into how testing is approached. Planning techniques include release planning, sprint planning, tools like the definition of done, techniques such as test first development (including test driven development) or classic test planning documentation.
  2. Test Goals – Test goals reflect an organization’s business strategy and needs. Test goals can be as simple as ensuring software is defect free (this is not only simple, but a simplistic) to improving the product’s delivered quality (as compared to a standard or a baseline).
  3. Test Policy – A policy defines a course of action that supports a long-term purpose. A test policy describes the type of behavior without defining the ends, means or approach. Good policies are aligned with the business strategy and the test goals. Test policies must be agreed upon (at least passively) by all of the stakeholders.  Policies that the involved parties don’t agree with will potentially generate poor behavior as stakeholders struggle against what they perceive as artificial constraints. For example a policy that requires all applications to be stress tested even if they are standalone, one person applications will not be perceived as fitting the environment.  The policy will be ignored when practitioners don’t think it applies which opens the door for failure if something is not stress tested that should be.
  4. Test Strategy – At an organizational level, a test strategy represents a broad outline that will orperationalize the test policy.At a project level, a test strategy will define the how the project will conform to the test policy and meet the test goals. The strategy operationalizes the testing goals and policies based on the business and project risks.

The typical image painted when discussing test planning is an omnibus document that defines how a project will approach testing, sometimes in mind-numbing detail. While that level of detail might be important in some scenarios, in most Agile projects the adoption of standard techniques provides the policy, strategy and guidance to ensure a good test planning. Agile techniques that improve planning include:

  1. Well-formed user stories (including acceptance criteria),
  2. Test first development (such as test driven development or acceptance test driven development), and
  3. A solid definition of done.

Planning is requirement for any activity development activity, testing included.  Good planning is a requirement for good testing.

The schedule is not the enemy when used correctly.

The schedule is not the enemy when used correctly.

I recently asked a group of the Software Process and Measurement listeners why they hated schedules. The focus of the question was not on plans, which are documents that provide strategic direction but rather schedules which are more task oriented. The respondents were a mixture of scrum masters, project managers, process improvement leaders and change leaders primarily in software development, enhancement and support. I should note that by being readers of a process blog and/or listeners to process-related podcast the respondents marked themselves as lifelong learners and perhaps a bit outside of the norm (in a good way). However, the top five answers were:

  1. They are generally wrong. Schedules, especially anything over a longer time horizon, establish an expectation. These schedules reflect best guess and best intentions and rarely standup to what as teams wrestle with delivering value. There are all sorts of techniques to try to anticipate schedule drift, like adding padding. These techniques are tacit admissions that the schedules are generally wrong.
  2. Schedules prescribe how a problem is to be solved. A detailed schedule is the embodiment of a solution; listing the tasks that specify what is to be done and when it needs to start and be completed. However, as most projects progress, the solution as it was originally conceived, evolves. This renders a detailed schedule moot.
  3. Schedules are someone else’s idea of what should happen. Project managers or tech/test leaders are often tasked with creating schedules (this even happens on Agile teams when someone else breaks tasks down and assigns the work). Schedules are created with input or buy-in from the team doing the work yielding animosity and stress from the team. Release and iteration planning are Agile’s solutions to these problems.
  4. Schedules reduce team behavior. One attribute of an Agile team is supportive behavior. Teams commit to work and then, when needed, swarm to tasks and features so that the team can meet its commitment. Detailed project schedule commits team members to performing specific tasks in a specific order.  The schedule gets in the way of team members being able to use self-organizing techniques like swarming.
  5. Detailed schedules take a huge amount of upkeep. One respondent suggested that for any project scheduled to take more than a year to complete, one person should be allocated to maintaining the schedule. That included chasing team members for updates, resolving conflicts and in general being a pain. Other respondents were less specific, but indicated that the cost of the schedule was more than the value.

The question generated responses that were oriented detailed project schedules typically found in projects managed using classic project management techniques.  A few respondents pointed out the value of detailed project schedules. Some of the benefits included the ability to distribute and direct work across distributed teams and to facilitate a discussion of when the project would deliver. It should be noted that these responses came from more command and control oriented organizations. Respondents with a background in Agile tended to point out that while they did not feel that a classic project schedule made sense, the combination of product backlog and sprint level task list was a necessity.


A map is a plan.

A map is a plan.

All projects should have some sort of plan. Whether that plan is a classic project plan and schedule or a prioritized backlog and a release plan. A plan helps answer stakeholder questions and, perhaps more importantly, it reflects the philosophy of the project. In order for a plan of any type to be helpful, the plan and philosophy must be possible. Bob Ferguson (Listen to SPaMCAST 240) said that there were ways to detect a plan what was not possible. Several of the rules of thumb that Bob suggested (augmented with a few of my own) are:

  1. Difficult work is done late. This is on both of our lists. Teams that avoid addressing difficult or technically complex stories backload risk, which can impact a project’s ability to deliver value. Conceptually this problem should be harder in Agile, assuming stories or features are prioritized in value order and the inter-relationship between features is factored into the value discussion.
  2. Learning is not explicitly planned. Any project that is creating new features or a new product should have prototyping built into the process used to gather requirements and build a backlog. Experiments/prototypes also can and should be used to prove solutions that are complex or cutting edge (at least for the team). This item was on Bob’s list and not on mine; it is now.
  3. Rate of story completion is not feasible. If the plan can’t be completed given the team’s (or teams’) level of velocity or productivity, then it is a bad plan. Plans that specify the amounts of functionality to be delivered, the date of delivery and the budget to be spent have credibility problems, however when they are developed using wishful thinking productivity rates they enter into the impossible range. This one is on my list and not Bob’s (in your face Bob).
  4. Belief that the plan — is THE Plan. A plan, schedule or backlog that does not change for a project of any moderate or large size is wrong or if it actually works is  the reflection of sheer dumb luck (Harry Potter reference – reread Harry Potter and the Philosopher’s Stone.). Anyone that falls into the trap of absolute belief that any project deliverable can be created once and referenced forever will find delivering value difficult at best.
  5. Not involving the business. The real product owner(s) must be part of the product to act as an active conduit of business acumen into the team to minimize wait and search time. All too often business stakeholders have been taught treat the boundary between IT and the business as a demilitarized zone where information hand-offs occur on a periodic basis. This behavior makes planning and maintaining any sort of plan difficult at best which slows the project down. IT teams often elect proxy product owners from inside the IT boundary leading to the same result (I heard this termed all of the responsibility and none of the authority). Proxy product owners can’t provide the level of feedback on priorities and the plan that the business can.

Plans have value only if they are current and only if maintaining plans, schedules, backlogs and the release plans do not become the goal of the project. Planning helps teams to develop a strategy for delivering value, but they must be allowed to change. Change is inevitable because we are learning both personally and about our project everyday. Not using what we learn is silly!