It’s like kissing your sister

Why we should always strive to complete stories and tasks in the committed sprint

One of the most common missing attributes of teams struggling to adopt agile practices, particularly in a Scrum framework implementation, is the dedication to complete what was committed to.  Especially when coming from a waterfall background, where the exception is to complete on time (as per that glorious project task tracking sheet) and the norm is to have tasks slide.  And slide.  And slide.  Many of us have been conditioned to believe that this is ok because:

• “the original date was not realistic anyway”
• “The task grew to more than I expected”
• And the all-purpose “but I had to wait for this other thing to get completed”

Agile, and Scrum in particular, is very much about making us predictable.  Moving stories and tasks from one sprint to another (and another, and another) should be like kissing your sister; you will do just about anything to avoid having to do it.  (I grew up with 4 brothers so I can’t say for sure, but I think you get the point).

We have made a commitment to complete a set of work so that we can provide an agreed upon value to the business; our predictability is being counted upon to maintain the cadence of Scrum, and to build the trust from the organization that we will complete what we set out to do.

How do we become predictable?  How do we create a pattern of meeting these commitments?  It’s not by padding our estimates; that will make us predictable in a very bad way.  It’s not by overworking and going down the ‘death march’ path; that’s not sustainable.  And it’s definitely not by laying blame elsewhere; agile is all about personal accountability, team commitments and transparency.   We become predictable and create this reputation for meeting commitments by breaking things down appropriately, maintaining the proper level of communication, and by having a clear view of what done looks like.

How to avoid carrying stories from sprint to sprint

Humans are terrible at predicting very far out into the future.  When we try to predict how long something will take, the bigger the effort the worse we are at predicting the completion time.  When we invest time in making that long range prediction more accurate, we only succeed in extending the date out further; hence making the prediction even worse.

Break it dowm

When we break things into smaller chunks we not only can predict with more accuracy how long it will take, we also gain a ton of knowledge about what that value is and how to provide it.

In Donald G. Rienertsen’s excellent book “Principles of Product Development Flow” he illustrates this fact with the 6^th and 7^th principles of Product Development Variability.  In the 6^th principle he describes how forecasting becomes easier at shorter time-horizons as we are able to better predict the size and scope and also increase the speed of development (through less uncertainty, amongst other benefits).  In the 7^th principle he illustrates how many small experiments (tasks) produce less variability then one big one; resulting in faster feedback and reduced variability in the outcome (read: Predictability).

Don’t Overcommit

Superman says “Don’t worry ma’am, I’ll stop that train”, and the action hero always tells the distressed damsel “I won’t let anything bad happen to you”.  Big promises, but whether through superpowers or a Hollywood script they know they can back it up.  We are not Superman nor are we action heros, overcommitting in the real world just gets people hurt.  So, why do we try? 

The reality is that the real heroes are the ones that understand their limitations and what they can and can’t do.  They don’t put their team’s reputation in jeopardy by overstating what’s possible.  (In the same light they don’t sell their team short by under committing either).  The tricks to this step are to learn from recent history.  What did we get done last sprint?  Did we over or under commit?  If we over committed, what was the main reason?  Were we optimistic?  Did we not see the risks or dependencies in the committed work?  One of the great powers of the Retrospective is to answer questions like this, to inspect and adapt by improving our tasking and commitments.

Planning for Done

Dwight D. Eisenhower once said “In preparing for battle I have always found that plans are useless, but planning is indispensable.”  We task out stories to find the inherent risks and dependencies in a story, not to track our time.  Working together as a team at the beginning of a sprint to task out the committed work will identify many hidden risks and dependencies early on, as well as lead to a confidence factor in completing the work.  If risks and dependencies are discovered, or the confidence factor is low, early in the sprint is the time to discover this.

However, do not mistake this for a waterfall in a can.  We task out enough to understand how we will approach the problem, but we don’t write a full on requirements document before we get started.  We share a common understanding of the acceptance criteria, but also understand those may change slightly as we learn about the feature during the sprint.

Swarming

The practice of swarming on a story is under-utilized in most scrum teams.  Look for a blog in the near future on this topic, but essentially this means everybody that can works on the top priority story until it's done.  I equate this to bees on flowers; as many bees as possible go to the first flower, if it's full then the remaining bees go to the next flower.  However, the bees don't spread out across the entire field, they stick together and move from flower to flower almost as a unit.

Forces from above...

One of the primary reasons for overcommitting or taking on too big of a chunk in planning is the forces from management and product ownership to “get more done”.  That kind of pressure is ok; management and Product Owners should expect a lot out of their agile teams.  However, make sure that from a team perspective you are counterbalancing that pressure with the right amount of reality (through conversations during planning and backlog grooming ) and predictability.  It becomes far easier for management to accept what they consider a smaller commitment once they become used to the fact that what is committed will be completed.  It is better to under commit as you work to get better at these practices; having time available at the end of the sprint is not as anti-productive as you might think.  Become predictable and the trust from management will follow.

Avoid the Icky…

When planning out your sprints, keep this in mind: At the beginning of the sprint you made a promise to your product owner to provide a certain amount of value.  Make sure your plan convinces you that you will be able to uphold this promise.  Take a confidence vote on the plan, raise your voice when you don’t feel comfortable with the plan, ask the right questions at the beginning of the sprint.  If you miss that goal, inspect and adapt during the retro to address the reasons for falling short and follow through on the proposed actions that result.  Becoming predictable should be one of a team’s few top goals.  Work to make sure you don’t have to kiss your sister again.