Done-Related Story Estimation

In today's Backlog Grooming I tried a new method of estimating user stories. The estimations were based on and related to known done-stories of former sprints. The method is very simple and contains only five steps. 

Step 1: Get user stories from Product Owner

Your Product Owner should be prepared for Backlog Grooming and bring his top-priority stories for discussion and estimation.

Step 2: Select reference stories

Pick a few random stories from your already done stories. Make sure their story points differ enough so a typical mixture of story points is in the set. In today's experiment I chose stories with 3, 5, 8, and 20 points.

Then write a new reference story card for each of them in the following way: write the story on the front of the card and write its story points on the back of the card. Make sure to hide the story points from the team's eyes for now.

Step 3: Sort user stories

Let the team find the right order of old reference stories and new undone stories. You will notice much more comparative conversation on the stories than with playing Planning Poker.

Step 4: Show story points

Now the fun part begins. Turn the reference stories and surprise the team by showing the reference story points.

Step 5: Adjust stories and story points

Let the team discuss if any adjustments are necessary. There will be more conversations on single cards to gain more understanding. Some stories may change due to these conversations. Take care that stories with high points get split properly. In today's example the story at the bottom with 20 points could be discussed and split into two stories. The result was much deeper understanding of the real value for both the team and the Product Owner. 

I'm looking forward to the Sprint Planning meeting next Monday.

Book: Harrison Owen - Wave Rider

Everyone dealing with self-organizing teams should read this book!

Authors: Harrison Owen

Title: Wave Rider: Leadership for High Performance in a Self-Organizing World

Rating: highly recommended

Have you ever wondered why in a well-defined organization there are always a few "key" people who know how things really do work? Have you ever thought about how to plan and deliver the daily food supplies for several million people? Read this book to find out.

In the first part of this book Harrison Owen offers deep theoretical insights of High Performance Systems, Self-Organization, and Open Space Technology. According to his definition, the three major elements of High Performance are chaos, confusion, and conflict, which lead to wholeness, health, and harmony--be it in small teams or large organizations. He states the necessity of grief work at the end of anything, and that--although highly important--such grief work rarely happens. The reason of missing self-organization is the need of control coming from traditional habits and thinking.

The second part of the book is written for practitioners and shows "eight essential steps for the care and feeding of self-organizing systems":

1. Do Your Homework Before You Start.
2. Extend an Invitation.
3. Come to the Circle.
4. Welcome Passion, Responsibility, and Authentic Leadership.
5. Remember the Four Principles.
6. Observe the Law of Two Feet.
7. Keep Grief Working.
8. Formalize the System.

This may sound weird at the first look but it gives a very nice description how Open Space works and how to do it.

The book is an eye-opener and offers so many insights why and how self-organizing systems work. The level of understanding one may reach by reading this book is not restricted to Open Space but is applicable to any organizational structure.

Book: Henrik Kniberg - Scrum and XP from the Trenches: How We Do Scrum

This is the must-read book for any new agile team member!

Author: Henrik Kniberg
Title: Scrum and XP from the Trenches: How We Do Scrum
http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
Rating: highly recommended!

Are you dealing with new agile team members from time to time? Do you have to train and explain agile to developers, testers, managers? Do you need an easy to understand book on agile practices? Do you need a highly practical book on how to do Scrum and XP?

Get a copy of Henrik Kniberg's outstanding book and just distribute it to your audience.

This book is full of practical information and shows a very pragmatic approach of implementing Scrum and XP practices with an agile team. It covers almost all aspects and is really easy to read and understand.

Although in my opinion there is no best practice how to be agile--this book just shows a great way how it works. I give this book to all my teams and other people new to agile. It's just a great start to learn about agile practices.

Book: How to Read a Book

Everyone reading a large number of articles and books could read this book.

Authors: Mortimer J. Adler, Charles van Doren

Title: How to Read a Book

Rating: interesting

This book was one of many recommended readings from my survey at ACCDE10. The title was promising so I decided to give it a try.

Many aspects of the reading task are covered in both theoretical and practical ways. Four levels of reading are distinguished:

1. elementary reading - nothing more or less than the ability to read and understand written text
2. inspectional reading - the ability to skim and browse quickly through a text
3. analytical reading - the ability to get into the details of a text as well as understanding and criticizing an author's messages
4. syntopical reading - the ability to analyze and put a text into the context of related books on the same topic

The book offers many practical advice on how to read texts of specific kinds like e.g. history, novels, mathematics, and practical books.

I made the experience to have applied some of the practical advices to the book itself. So I skipped some 40% of the actual content of the book - and I don't feel bad about it. I assume such reading behavior was intended by the authors.

On the other hand I'm still puzzled if the book is worth its 400 pages. I'm sure the essence of the book with all its advices and "how to"s would fit on less than 10 pages. The authors probably should have read something like "How to write a book". Nonetheless the book is interesting and to read it may serve well for a reflection on one's own reading approach.

Let the Team play Product Owner

Today I made a nice but rare experience: team A could play Product Owner for team B.

Team A is settled since several iterations and is working on a new product. Team B is only a few days old and is going to build an internal, technical product to emulate the behavior of depending external hardware.

As the developers and testers of team A are going to be the real users of team B's product it was obvious to do a short user story workshop with them. So I gathered everyone of team A around a table in the team room bringing some blank index cards and a marker to start with.

I made several interesting observations during the workshop:

• Some developers show the same behavior as many customers do. They have problems to state what they want to achieve and rather base their statements on the currently planned product features.
• Some developers think very broad so that new themes and stories emerge no one had thought of before. Of course these stories look obvious afterwards but nevertheless would have been forgotten if the real users were not involved.
• Some developers fully understand the agile roles and do not care about the technical implementation. "I don't care how they realize it but I want to have this and that."

We finished that session with a dozen user stories which will result in many more smaller stories after some backlog grooming. I'm going to do the grooming exercise with the team as well so they have the chance to get more and deeper insights into a Product Owner's work and responsibility.

A team and it's Product Owner need mutual understanding and a prospering relationship. In the end it's again--as almost always--a game of Individuals and Interactions.

Recommendation to Scrum Masters and Agile Coaches: let the team play Product Owner every now and then.

CCD Reflection 2: Red Grade finally finished

Four weeks have passed since my last CCD Reflection. So today is day number 49 of wearing the CCD Red Grade wrist band which is quite a lot of time staying with one single CCD grade.

What have I done in the last four weeks?

• Weekly Coding Dojos with my team
• Thought about features and user stories of an online CCD Reflection tool to make daily reflections easier
• Took Industrial Logic's eLearning course on "Composing User Stories"
• Worked on the formal proof that agile practices match very well the software life cycle requirements of specific laws and regulations. But well, this is way too off-topic here.

How do I rate my performance on the principles and practices of the CCD Red Grade?

• DRY - highest rating
• KISS - high, still room to improve
• Beware of Optimization - high, no longer skipping TDD baby steps but from my gut feeling still room to improve
• FCoI - high, I initiated a design session with the team to talk about FCoI. One guy came up with FNoCaI: Favor Nothing over Composition and Inheritance - which sometimes could be the best choice.
• Boy Scout Rule - lowest rating due to 100% work on new, fresh Kata code
• Root Cause Analysis - high, this just belongs to my daily job as team coach and Scrum Master, at least in the last four weeks
• Version Control - high, nearly 100% done
• Simple Refactoring - highest rating, completely done as integral part of doing TDD
• Daily Reflection - medium as I have thought about developing an online CCD Reflection tool

I gave every of these principles and practices a value from 1 point (not done at all) to 5 points (perfectly done), see image.

Red Grade finished for now!

Although I wrote in my last post ...

It would be meaningless to go on as long as I fail to apply the boy-scout-rule, root-cause-analysis, and daily reflexions on a regular basis.

... I'm going to switch to the next Orange Grade by tomorrow morning simply because it's the right time to do so from my point of view. I'm just too excited to experience the next grade. Expect feedback in at least 21 days here again.

CCD Reflection 1: Red Grade finished

Today is day number 21 of wearing the CCD Red Grade wrist band and time to reflect on the last three weeks.

What have I done in the last three weeks?

• Several code katas
• A little pairing with one of our developers to find weird UI problems
• Initiated the first Coding Dojo in our team - we are going to do weekly Dojos now

How do I rate my performance on the principles and practices of the CCD Red Grade?

• DRY - everything was done only once, I give a high rating
• KISS - almost everything was kept simple or--even better--was made simpler
• Beware of Optimization - I can't remember any optimization but want to rate "not perfect" as I think that some shortcuts were made during TDD (two or more baby steps at once). And taking shortcuts is some kind of optimization as well.
• FCoI - my kata and dojo code was too simple, FCoI could not have been applied
• Boy Scout Rule - interesting experience: during a debugging session we walked through code and saw dirty places BUT at that time we were hunting a very specific system behaviour and did not want to interrupt this task by doing boy scout cleaning. Unfortunately we forgot to clean the code afterwards. Learned for next time: take a note of the dirty location and come back later to clean it.
• Root Cause Analysis - did not happen at all in the last three weeks
• Version Control - 50% done but not for some spiking code experiments and all my private katas
• Simple Refactoring - completely done as integral part of doing TDD
• Daily Reflection - thought about it but not very structured

I gave every of these principles and practices a value from 1 point (not done at all) to 5 points (perfectly done), see image.

Red Grade done, finished, or on-going?

The idea of the CCD initiative is to stay with your current grade until you are able to high perform on all aspects of this grade for at least 21 days in a row. My initial plan was to switch to the next Orange Grade after three weeks regardless of my red performance. I wanted to go on and focus on the next principles and practices - and simply keep in mind that I have to improve my red skills. Now I realize that CCD doesn't work this way. I want to prove significant success in the current grade to myself as a trigger to switch to the next grade. It would be meaningless to go on as long as I fail to apply the boy-scout-rule, root-cause-analysis, and daily reflexions on a regular basis.

I try to do daily reflexions from now on to get self-feedback early and improve my grade performance. To be continued...