Home > Agile, coaching, learning, Planning > Introducing Agile Planning with Apples, Chikoos, Raspberries, Jackfruits and Watermelons

Introducing Agile Planning with Apples, Chikoos, Raspberries, Jackfruits and Watermelons

Learning a new concept or process works best when done in a simple situation. Once you have mastered the process, you can apply it to more complex situations. I’ve made the mistake before of introducing relative sizing and velocity calibration to a group with the actual stories that were going to be used for the project. Though we’ve managed, there has always been a challenge of re-explaining the process throughout and pausing to discuss edge cases.

In a recent inception, I decided to introduce the concept first with an abstract example… fruit. I had worked this through in my head, and was happy that it would introduce the basic concepts and make the actual relative sizing and velocity calibration much easier. I was right on that sense, but it also did much more. We were able to see many real world examples and pitfalls come to light which made the actual relative sizing and velocity calibration go much easier.

Relative Sizing

To start with I had written about 30 different pieces of fruit down on story cards.  Rather than relatively size the stories based on the effort it would take to develop them, we were going to relatively size the fruit based on the effort to eat them!

Here are some of the lessons learned while doing the relative sizing:

The Technical Story

Things were moving along well and the team was making good progress through the sizing of the fruit.  Then came the kiwi… someone commented, “we need a knife”.  I asked them what they should do.  The team wanted to raise a story to buy a knife.  I asked what would happen if they played the knife story then the business decided not to play the kiwi story.  They quickly agreed that if we never played the kiwi, buying the knife would be a waste.  This led us to making an assumption that the kiwi story would include buying a knife, hence more effort.

When we later hit the pineapple story, we assumed that we already had the knife.  There was a brief discussion about what happens if the kiwi is deprioritised and the pineapple is not, and everyone was comfortable that the assumption of already having the knife would then be wrong and we would resize.

The learnings:

  • Do not create stories that will introduce technical infrastructure
  • Include the effort to do this in the first story that needs it
  • If multiple stories need it, make sure to assume the one that will be played first and assume in the others that it is already in place.
  • If those assumptions change, you resize the stories.

The Unknown Story

There were two other fruits that caused us trouble.  The jackfruit and the dragonfruit were both unknown to the team.  The jackfruit was easier to resolve.  One of the team members knew what it was and was able to describe it in enough detail for the team to size it relatively to the other fruit.  The dragonfruit was much harder (I was the only one who knew what it was).  Soon someone had an iPhone out and had it up on wikipedia.

The learnings:

  • The team should support each other by sharing knowledge about the stories, allowing them to come to an agreement on the size of the story
  • When the team doesn’t know the answer immediately, the BA should go away to discover the information.
  • Set the unknown story aside until the information is found
  • Capture any assumptions that you make

The Duplicate Story

Though we didn’t do this at the time, I’ve since realised that you could very easily include duplicate stories in the exercise.  Depending on where you are from and where you have travelled, finding fruits with multiple names may be a challenge.  Two examples are: carambola & starfruit and chikoo & sapodilla.  This would be a nice way to set everyone’s expectations that there will be duplicates and to keep an eye out for them.

Velocity Calibration

After the relative sizing, we moved on to velocity calibration.  We decided on a team size of two pairs and decided that we would have 4 iterations of 15 minutes each.  We asked the team to select the different fruits that they felt they could eat each iteration (with the assumption that they had a chance to digest their fruit between iterations).  Besides learning the basic concept, we also encountered what happens when you try to include your Too Big stories.

The Too Big Story

As we were doing the velocity calibration, we had one iteration whose velocity was quite a bit bigger than the others.  No prizes for guessing which fruit was included in that iteration.  After a bit of a discussion it was easy to see that we shouldn’t include the watermelon in the velocity exercise.  In fact we realised that the watermelon could be broken down into smaller pieces – think of the number of times where you have seen a half or quarter of a watermelon for sale in the produce section…

The learnings:

  • Exclude your Too Big stories from velocity calibration
  • Break your Too Big stories down, resize them and include the smaller stories

Summary:

When we repeated the exercise with the real stories.  The BAs and SMEs were aware that they needed to answer questions on the unknown stories, we excluded the Too Big stories from the velocity calibration, and the team was diligent at capturing assumptions.  Numerous times I heard someone comment “we need a knife for that story”!

Most importantly though, the entire team had done the fruit exercise.  SMEs, PMs, BAs, QAs and Devs were familiar with the process before going into the actual sizing and calibration.  For the devs the benefit was obvious, but the understanding from the other members of the team was invaluable.  Even though the other team members recognized that they could no longer participate with the exercises, they were engaged and involved throughout.  They took turns facilitating, answering questions when they could and rarely challenged what the developers decided!

Advertisements
Categories: Agile, coaching, learning, Planning
  1. Brian
    March 21, 2011 at 15:22

    Great idea!

  2. Pankaj
    August 11, 2011 at 13:12

    A really nice technique to introduce these concepts!

  3. Shree
    March 6, 2012 at 10:11

    I used it at one of the coaching engagements and got amazing results. We were able to draw lot of learning’s from this workshop and draw parallel with the actual story estimation.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: