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.  


Plan or CRASH!

At some point planning for planning needs to give way to planning.  Planning identifies a goal and helps to envision the steps needed to attain that goal. In Agile, the planning event also sends a message about the amount of work a team anticipates delivering in an iteration. While every team faces variations based on context and the work that is in front of them, a basic planning process is encapsulated in the following simple checklist.

Planning Preamble:  

As the team gets settled and before they leap into breaking work down into smaller stories, activities,and tasks the facilitator (e.g. Scrum Master in Scrum) should remind the team of the basics of planning, the ground rules, and expected outcome. The basics include:

___  How long the planning session will last (everything is time-boxed)

___  The time frame the team is planning for (e,g, a day, two weeks or several iterations).s

___  Everybody writes and everybody needs to participate.  

Not using a scribe tends to keep people involved. Also having everyone involved in the recording will help ensure that the records are not the sole responsibility of a single person which is a potential future constraint.

___ Decide on the planning order.

Planning order is often addressed in grooming, by organizational and/or team culture, or up front as part of the chartering. Review  the order and the rationale for it.  The three most prevalent ordering strategies are:
1. Hardest Part First
Highest Value First
3. Dependency Driven (those that can’t be avoided)

___ Definition of Done

Everyone in the planning should agree what the base components of done mean and whether anything out of the ordinary needs to be kept in mind during planning.  Remind everyone that done is not the same as acceptance criteria.

Business Context:

Providing business context is similar to reviewing the basics.  Business context serves many purposes, including motivation and answering the question of “why?” for the team.  Business context will help the team to make decisions more effectively and efficiently.  Business context items include:

___ Iteration Theme.  

The theme defines the overall goal.

___ Business Constraints

Are there business constraints that should be accounted for during planning?  For example, sometimes functionality is needed on a specific date due to legal mandates or other events.  One client had to plan to deliver a prototype for an industry show.

___ Important Discussion From Grooming

Grooming, like any business conversation, is a data gathering event.  Always share relevant information with the whole team.  


Planning is a process of decomposing work into smaller pieces.  Teams begin with groomed user stories and then break them into tasks.  Breaking the work down allows team members to gain a better understanding of what need to be done and how much work can be accomplished during the iteration.  Breaking work down also allows the work to be spread across the team based on capabilities and so that the team can swarm to the work when there are issues.   Considerations and guidelines include:

___ Take the first cut by breaking stories into big tasks before getting into the details.

This step helps teams not to get frozen into planning paralysis and into specifying the solution early in the process.

___ Target a consistent level of granularity for tasks.  

I recommend all tasks be slightly less than a day’s effort which makes it easy to show progress or to identify roadblocks quickly.

___ Plan out loud.

Planning out loud helps to keep everyone involved, away from silo thinking, and makes sure planning stays reasonable.

___ Plan slightly over capacity.

The team should plan a bit more than their productivity or velocity indicates.  The over plan represents a stretch goal and allows the team to  be positioned to continue moving forward if progress is faster than anticipated.

___ Remember to set aside capacity for maintenance and support (if needed)

Wrap Up:

Running out of time is not a great way to end a planning session.  Two normal steps help to provide  the team with planning closure

___ Review and commit to the plan.

The team should be able to agree that they will accomplish the plan based on the planning exercise.  I suggest testing commitment as planning progresses. However if the team can not commit to the plan, the issue will need to be identified and another planning session convened to address the problem. Note: if the facilitator is testing commitment during the session, this should be a rare event.  When a team will not commit I generally find they have been forced to oover-commitby an external party.

___ Do a retrospective

As a team, identify one thing you can do better and commit to making the fix!

The simple planning session checklist is useful to get a team ready to plan, keep the team on track and to improve the process. I have used the checklist as a training tool and as a tool to help guide new facilitators.  

Next: dealing with common planning variations.    

Preparation is key to reaching your goals.

Successful and efficient planning of any sort represents the confluence of preparing the work to be planned and proper logistics. Earlier in this series on planning, we  reviewed the basic logistics needed for a planning event and defined a simple checklist.  While both are important, preparing the work to be planned requires more effort.  Preparing the work for planning requires knowing the capacity of the team and grooming the work items (stories, requirements, support tickets and/or defects). (more…)

Logistics Are Part of All Meetings

Planning Meetings are not terribly glamorous.  They are, however, an important first step in effectively delivering value for any sprint or increment.  I have developed a simple checklist for preparing for a planning meeting (we will explore a simple process in the near future).  Agile planning events couple the discipline of saying what will be done and then delivering on that promise with the need to embrace the dynamic nature of development and maintenance. (more…)

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

SPaMCAST 450 features our essay on Product Roadmaps.  Roadmaps link an organization’s strategy to action. Product roadmaps are directional and answer the question of where we are going and why. As with any powerful tool, roadmaps giveth when used wisely and taketh away when used less wisely.

We also visit with Gene Hughson.  Gene brings his great Form Follows Function blog to the podcast.  We discussed the entry Holistic Architecture – Keeping the Gears Turning.  After you listen to our conversation remember that roadmaps are a way to avoid your products not to resemble a bunch of spare parts flying in close formation.

Re-Read Saturday News

Today we will begin the next book in the Re-read Saturday Series, The Science of Successful Organizational Change. Steven Adams (SPaMCAST 437, SPaMCAST 412 and nearly every entry in the Re-read Saturday series) will lead this re-read.   Remember to use the link to buy a copy to support the podcast and blog.

Steven begins the re-read by describing how he found the Paul Gibbon’s book “The Science of Successful Organizational Change” (get your copy) searching “Agile Change Management” on Amazon.  

A Call To Action

You can help the podcast. If you even got a single new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes, Stitcher or wherever you are listening.  If you leave a review somewhere, please send a copy to  Reviews help guide people to the cast!


SPaMCAST 451  will feature our interview with James Shore.  We began with a discussion of the Agile Fluency Model, the concepts, and ideas that led to the model and then got into topics such as whether Agile can ever be method agnostic.  

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

Map of the Fredrick Half-Marathon

A product roadmap is a powerful tool.  Roadmaps help link products and services to the strategy, objectives and key results.  Roadmaps are directional, answer the question of where we are going and why.  Roadmaps are powerful – unless they are messed up!  There are four common mistakes that will reduce the value of a roadmap. (more…)

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

SPaMCAST 448 features our essay on uncertainty. Al Pittampalli said, “uncertainty and complexity produce anxiety we wish to escape.” Dealing with uncertainty is part of nearly everything we do our goal should be to address uncertainty head on.

The second column features Steve Tendon talking about Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban published J Ross (buy a copy here). We tackle Chapter 18.  

Our third column is the return of Jeremy Berriault and his QA Corner. Jeremy discusses leading in  QA.  Jeremy  blogs at

Re-Read Saturday News

Chapter 10 concludes our re-read of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson which was published by Henry Holt and Company in 2015.  This week’s chapter is titled, The Experience of Holacracy. In this chapter, Robertson wraps up most of the loose ends. Next week we will conclude this re-read with some final comments and thoughts. (more…)

Next Page »