Time box: A Holistic View on Sprints and Iterations

imageOver the last few years we’ve seen a growing discontent around the idea of Iterations or Sprints.  It excites me that the software community is actively engaged in questioning the long held canon of Agile practices.  Through these explorations we as an industry will find a greater depth of understanding.  Over time this can only have a positive impact on our community.

In reading many of the Iteration abandonment stories and views on why iterations are outdated I believe there is a rather one sided understanding of Iterations.  I believe this is a remnant of the software development industry’s state of being from which we came; the way referred to in the opening line of the Agile Manifesto.

We are uncovering better ways of developing

            ~ opening line of the Agile Manifesto

I have a confession to make: I think iterations are really, really useful.  I also think they are often bastardized.  I’d like to help fix that problem and, in so doing, bring some of you back to the iteration so you can be more creative and strategic and less, well, cogs in a wheel.

In a three part series of posts I will redefine the meek, abused iteration for you as a:

If you really, really want to love going to work, experiment with cool new technologies and techniques even in the most conservative organization, and want the best argument for ‘going Agile’ then stick with me.  By the time we’re done you will have a better understand of what a time box really is, where the time box applies, where it corrupts and, how to make a balanced decision for the duration of your next time box.

Definition of Done Discovery

One of the important aspects of Scrum and the more fundamental concept incremental delivery is building Done software each iteration.  There are a lot of holes in that statement, but that makes sense; Scrum is full of holes… on purpose.  If you want answers rather than a framework built for learning, Agile ain’t for you.

imageHaving a clear, well understood and explicit Definition of Done that everyone, including your product owner and surrounding teams accept is very important to growing quality and capabilities consciously.  Underlying any Definition of Done is the expectation that the useful (for another day) software is ready for consumption by those who asked for it.

As a new team, discovering your initial definition of done can be surprisingly challenging.  Certainly we can come up with things that we want to do and I say go for it!  Only inspection at regular intervals can tell us for sure where we are and what the impact has been.  But there are some things we can do to help make this decision more effectively.  And it doesn’t take long.  30 minutes… maybe.

Circles and Soup

Innovations Games has a fantastic activity with many applications called Circles and Soup (sometimes called The Soup).  I’ve used this to help a pissed off team focus their energy, but it’s also very helpful in creating an initial Definition of Done that is truly attainable.

You should read the full instructions, but suffice it to say the team will categorize those activities both historically done (i.e. architecture review) and potential (i.e. TDD) that must or should be accomplished to deliver into: Things They Control, Things They Influence, or The Soup (things they have no control or influence over).  This is immediately actionable information, but also a roadmap to move items into the teams control.  Share this with your organization and advocates.

A Definition of Done, something that they agree will always be completed before calling a feature or story or product backlog item done, which includes activities outside of the team’s control is risky or foolish.  You should control your own destiny as best as possible.  How can a team ever feel at all confident in their own forecasts otherwise.


In the Professional Scrum Developer course we talk about and spend a few minutes brainstorming attributes that define quality.  We call these ‘ilities’.  Things like maintainability, supportability, reliability, performance-ability.  Ok I made that last one up, but you get the idea.  It’s a big list too. 

Very few people will argue that missing an -ility negatively influences the quality of an application. Which –ilities are most important, though, depends on many factors.  Type of application, type of user, industry, etc.

What I like to do as a facilitator for this activity:

  1. Ask the team to break up in pairs or individuals for 5 minutes.  Write every attribute that affects your impression of any application you’ve ever used on a sticky. 
  2. Then come together, remove duplicates and put them on the wall for another 5 minutes (usually less).  This creates discussion about what people intended or experiences.  Often another -ility or two will be discovered.
  3. Use dot voting or some other form of ranking to figure out which –ilities are most important to this application.
Putting it together

You should now have a good idea of what the team has true ownership of and what is most important to build a great application for the intended customer.

With the results on either side of a whiteboard or giant sticky, choose a few activities which correlate the important –ilities and the activities in the team’s control to determine an actionable, checkbox-able list of things you feel will assure each feature and sprint produces Done software.

Each iteration you have the opportunity to review these artifacts or recreate them to evolve your Definition of Done from good to great.

Cone of Uncertainty Graphic with Events in Time

I’ve always received great feedback when describing the cone of uncertainty to groups on a whiteboard using events in time rather than simply an abstract timeline.  Today I put a graphic together that I can easily share or refer to.  Thought I’d post it for others as well.  Feel free to use it and let me know what you think. 

Disclaimer: All events are provided as examples which can and may occur as you work toward solving a problem.  I’m not advising you to include these explicitly in your process.


Rules of the Game: Effective Group Discussion

Meetings are hard.  They can easily suck the life out of your day, week, or *gasp* job.  Let pain be your guide. (Thanks @coreyhaines)

I recently had to work through a mountain of feedback data provided by a limited product release.  User Experience experts, random individuals, and customers known for their willingness to provide quality feedback gave us excellent information.  The question became how do we effectively process the information as a team. 

Here a redacted version of the meeting notice I sent out:

We have feedback from some users. We need to talk about it, but it’s a lot of info.

Here’s the tentative plan (tentative because someone might think of a better one).


15min · Soapbox

30min · UX Feedback

30min · Customer Feedback

15min · Next Steps


We need a really, really good note taker.  Volunteers?


Rules of the Game

  1. Each person receives 3 uninterrupted minutes for their soapbox.
  2. Interrupt someone during their soapbox and you lose a minute from yours.
  3. Maximum 5 minutes on any one feedback item.  Action item to dig in later.
  4. Fist in the air by anyone immediately halts discussion on the topic and we move to the next. Action item to dig in later.
  5. Add a sticky note to the wall if you want to discuss something relevant by off topic.
  6. Try to have read as much of the feedback as possible before the meeting.

The key to any meeting is preparation and an effective recorder.  By having a timeboxed agenda, audible timer, rules, and an awesome recorder meetings can actually be fun! 

I love the Soapbox for two reasons.  First it gets everyone talking.  Even the quiet person has three minutes (or a really long, awkward silence).  If someone finishes before their allotted time, sit quietly (you kinda have to or you lose a minute yourself!).  They will probably come up with something else right before their alarm buzzes. The second reason I love the soapbox is that you can then get down to business without people interjecting something off topic.

We didn’t make it through everything, people were cut off by the alarm, and people didn’t get to say everything during their soapbox.  It’s ok.  Do it often and people will learn to be direct, to prioritize their thoughts, and to PREPARE.


Now, back to my code.