Agile Planning & Estimating – Checks and Balances

 

There is a common myth that Agile is undisciplined.  The lack of a uni-directional, sequential process associated with traditional approaches to software development is interpreted to mean that Agile has no process.  This could be no farther from the truth; as a matter of fact, one could argue that Agile has lots of process and actually requires a greater level of discipline compared to traditional approaches.  Agile’s iterative and incremental approach takes a project and splits it into many small increments, so planning processes are repeated often.  This provides many opportunities to include checks and balances to help keep things on track.  This post focuses on some common checks and balances around two key parts of the Agile process: estimating and planning.

Background – The Agile Planning Process (Stories, Estimates and Tasks)

Requirements on an Agile project undergo a process of being defined in increasing levels of granularity as they evolve.  Most requirements start out as Epics, very large features that an end user representative or Product Owner (i.e. Customer) can easily relate to.  However, Epics can’t be implemented, they are often much too large to be completed within an Iteration or Sprint and need to be split into multiple, smaller User Stories that the development team can assign to Sprints.

A Backlog is an inventory of all of the Epics and User Stories associated with a development project or initiative.  The team, usually the Business Analyst, collaborates with the Customer to keep the Backlog up to date by adding, updating and removing Epics and User Stories.

Estimating is important because the effort needed to develop a feature helps the Customer establish priorities within the Backlog by being able to weigh effort against value.  Epics and Stories should be estimated by the development team as soon as they are added to the Backlog or changed in any way that may affect their scope.  Epics should be estimated in terms of weeks of effort to build the feature and Stories can range from 1 or 2 days of effort up to 10 or more days.

Task planning happens when a Story is ready for implementation and is where the team splits Stories assigned to a Sprint into implementation Tasks.  Tasks represent everything that needs to get done to complete the Story and are not necessarily technical—Tasks can include configuration, testing and documentation type work.  Task planning represents pull-mode work assignment and facilitates the Agile principle of self-organizing teams.

Estimating Tasks is optional as they do not need to be prioritized by the Customer (the team does this when they start signing up to work on Tasks), but estimating Tasks is still recommended.  The usual approach is that the team collectively identifies all of the Tasks required for a Story on a whiteboard or somewhere visible and then estimates all of the Tasks in hours or part-days.

Estimating: Checks and Balances

Estimating requires the team to think about the effort needed to complete an Epic, Story or Task.  This helps to ensure that the team truly understands what they are about to build before starting to work on it.  As a result, estimating can expose many potential problems:

  • Is the team able to come up with an Estimate easily?  Or does coming to a consensus seem like a struggle?
  • Is there debate around what really needs to get done?  Or is there uncertainty about the scope?
  • Is the Estimate reasonable?  A really high number suggests lack of understanding and increased risk.
  • Is the team going into too much detail ending in paralysis? Estimating is an effort at sizing to assist planning, not for implementation.

If one or more of the above situations is evident then the team needs to stop and consider possible actions to address an estimating problem. Perhaps the Epic or Story needs to be put on hold for planning (possibly by lowering its priority) to create time to analyze it more.  In some cases, it may make sense to split the Epic or Story up into multiple, smaller items (which may have varying priorities).  With task planning, one option may be to run a spike by adding a time-boxed Task to drill into something specific to learn more before proceeding with the rest of the Story.

Planning: Checks and Balances

Planning is a continual process in Agile and provides frequent opportunities to inspect, by monitoring Estimates, and adapt, by updating the current plan as needed.  Two common examples of misalignments (blow ups) include:

  • During backlog grooming the estimates for Stories should be compared to the estimates for the Epics they are associated with
  • When task planning, the sum of the Tasks identified for a Story should be compared to the original Story estimate

The team needs to be constantly on the lookout for these sorts of problems and act on them promptly.  The first step should always be an internal discussion amongst the team to make sure the problem is not obvious.  Perhaps there was some misunderstanding around the implementation.  However, if it becomes clear to the team that the original Estimate was wrong then more drastic action may be needed, such as:

  • Deferring the Epic or Story to later to leave more time to investigate it further
  • Removing an external dependency
  • Splitting the Epic or Story into smaller pieces
  • In the case of task planning, removing lower priority Stories from the Sprint plan to make room for a higher priority Story that ‘tasked out’ higher than expected. However, removal of scope from a Sprint should not be done without first consulting with the Customer.

When there is a blow up the cause sometimes can be due to a systemic estimating error; that is, an error that affected one Story that may also affect future Stories in the Backlog.  A good example is an incorrect assumption.  When this happens, the team should revisit their original Estimates for future Stories in the Backlog to ensure that they are still valid, adjust them where necessary, and advise their Customer as this may change their priorities and plans.

Conclusion

Agile is about risk management.  The checks and balances outlined here provide mechanisms to help manage risk by ensuring that something doesn’t end up being planned or built before it has been thoroughly vetted by the team at an appropriate level of detail.  This enables the team to make commitments to the Customer, either by assigning Epics to Milestones or Stories to Sprints, and successfully deliver on those commitments.  This helps earn the trust of the Customer which gives them confidence to make changes to the plan and know that the team will be able to deliver on a consistent basis.

 

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply