Proof First!

Iteration planning would be far simpler if every story was started and completed during a single iteration, if every story was independent, or deadlines did not pop up messing up carefully crafted prioritization routines.  Unfortunately, real life is a bit messier.  Having a strategy to handle variations from the best case makes life easier.  A few of the common planning glitches are:

Expedited Stories – Most teams adopt some form of prioritization technique (examples include weighted shortest job first, hardest part first, and highest business value). Expediting a piece of work includes addressing the item out of order or asking the team to accelerate the item so it can be completed faster. The simplest coping mechanism is to have the product owner (and the person asking that the work is expedited, if different) identify which planned work items should be put on hold to accept the expedited work.  Expediting work items puts stress on the team and often sends a message that lack of planning is acceptable.

Deadlines – Dealing with deadlines (sometimes emergent) is a variation of expedited work.  The easiest coping mechanism is to build deadlines into the prioritization and grooming process so that deadlines are accounted for early in the planning process.  Problems crop up when deadlines are accepted without regard for team capacity.  Trying to deliver more work than is possible will lead to a wide range of poor outcomes.  Another problem occurs when deadlines are set that are not based on need.  Artificial constraints can lead to the “boy who cried wolf syndrome” where real deadlines are ignored.

Carryover Work – While many will find it shocking, not every piece of work accepted into an iteration and started is always completed during the iteration.  The uncompleted work should be groomed, prioritized, planned and accepted into the next iteration just like any other piece of work. Often teams fail to reassess and groom uncompleted/carryover work and put these items at the top of the work being accepted in the next iteration.  Actively reassessing and grooming carryover stories is important to ensure that the story is properly formed and that if new information was uncovered that the stories are sized and prioritized properly.

Trivial Tasks – Accepting work that is of little or no value into the iteration should be avoided.  Well-formed user stories include the benefit/value they should deliver.  This should be true for a story delivering user functionality, an architecture component, technical items or even correcting defects.  If work has no discernable value ask the question, why are we doing this?

Recurring Tasks – Recurring task should generally be incorporated into the process (for example checking code in on a daily basis) or into the definition of done (for example, system testing or security testing).  Writing stories for recurring tasks is akin to implementing a waterfall approach with an Agile wrapper.

Spikes – A spike is a type of user story that is used to answer a question, gather information, perform a specific piece of basic research, address project risks or break a large story down. Fundamentally, spikes are used to address uncertainty by gathering specific information to understand a functional or technical requirement. For example, when the team needs to prove a specific technical problem or does not have enough information to estimate the story they would use a spike.  Spikes are an important tool that every Agile team should use when needed, however, they should not be overused.  Teams that over use spikes generally are missing a significant knowledge component.  Find a source for the missing knowledge and add that knowledge source to the team or leverage the source as a subject matter expert/consultant.

Work gets to an Agile team in a variety of forms and in the order originally planned.  Stomping your feet and saying no is rarely the right answer.  Each common variation in process and flow can be addressed if anticipated and if the consequences are known and accepted by the whole team and their stakeholders.