Why You Should Define Reference User Stories

If your organization is new to Agile one of the things you might struggle is the shift from traditional to agile estimation. I have seen a lot of inexperienced agile teams struggling with the nature of story points and relative sizing. Often a lack of trust in their own estimates, which led to poor planning, was the consequence. A simple tool, called reference user stories, helped each of these teams to overcome these difficulties.

If you haven’t defined reference stories with your team yet, consider well-defined, well-sized, not too domain specific user story from your past sprint(s) as candidates. Ideally you want to have reference stories of different size (e.g. 1, 2, 3, 5, 8 and 13 story points). Alternatively you can define artificial user stories that will serve as your references. Create a table of your reference stories, like the one below, and use it in your backlog refinement meetings. Feel free to add or exchange reference stories later if you feel the need later.

Size User Story
1 Story A: As a user I want to see my user name on the page so that I know that I am logged in with the right user.
2 Story B: As a user I want to write a comment to a topic so that I can express my opinion to the author.
3 Story C: As an administrator I want to block users for the forum so that I can prevent them from spamming.
5 Story D: As a user I want to register for the website so that I can use their premium services.
8 Story E: As a system administrator I want to migrate data from database A to database B via an automated script so that I can handle the amount of data.
13 Story F: As a user I want to purchase a product via the online shop so that the article is delivered to my home.

According to my experience reference user stories have the following main benefits for agile teams:

  • Supporting relative estimation: A user story (e.g. Story X) is relatively sized to the defined reference stories (e.g. Story A, B, C, D, E, F), which helps to focus on relative estimates (e.g. story X is bigger than story B, but smaller than story D) instead of absolute figures (e.g. story B will take 40 hours of work).
  • Increase accuracy of estimates: Relative estimates are more accurate, because our brain is naturally better at relative sizing then in absolute estimation. Defined reference stories also keep a stable reference and therefore reduce variability in the estimates.
  • Normalization of story points: Defining, sharing and using reference stories among multiple teams, normalizes their view on story points. With normalized story points we can calculate velocities for multi-team projects by just summing up the team velocities. (WARNING: Never abuse normalized velocities for team performance measures!)
Advertisements

My Management 3.0 Prezi (German slides)

From 12th to 13th of March I participated in a Management 3.0 workshop by Jürgen Dittmar in Munich. To present the highlights of the workshop to my workmates I decided to craft a Prezi. And here is the result of my first Prezi that finally made it onto a presentation screen (German slides):

prezi

 

The presentation went well (at least there was positive feedback). However I am still a novice Prezi craftsman and I welcome your feedback on my slides. Also feel free to reuse it for your purposes.

Better Feedback with a Happiness Door

My work as Agile coach includes regular training lessons with agile teams, product owners and other staff. Usually after a training or workshop I kindly ask the participants for their verbal feedback about the workshop, my moderation, the exercises, etc. A common practice that I just adapted from other trainers with the aim to improve my own training and moderation skills. Unfortunately the results of the verbal feedback rounds were not satisfying for me due to various problems:

  • Giving honest verbal feedback strait in the face seemed to be hard for my participants and therefore it was often omitted
  • Participants seemed to feel a barrier exposing their individual thoughts about the training in front of the group
  • Participants gave pseudo feedback by just repeating other’s feedback or giving hollow feedback
  • Only a few participants gave feedback at all
  • I hardly received constructive improvements (which is most interesting for me)
  • If there was plenty of verbal feedback after the training I often forgot most of it until I had time to reflect on it
  • Participants didn’t know how to express appropriate feedback

As a result I thought about alternative feedback mechanisms. I expected less problems with written feedback, which led to the idea to use a happiness door, a feedback mechanism created by Jurgen Appelo that I already knew from the management 3.0 workshop I attended some months ago.

Happiness-Door

 

Could the happiness door address my problems I had with verbal feedback rounds?

Yes. What has changed is that my participants felt safe to express their feedback semi-anonymously on sticky notes, which was not the case with the verbal feedback rounds. As a result I received more valuable feedback on my training lesson. Also everyone was willing to write at least one sticky note and because of less mutual influencing there was more individual feedback on the door. Finally seeing the feedback visually in front of me on the happiness scale was just great, because it gave me an instant feeling about my training performance and also helped me to remember a feeling of the training lesson. After the training I spent another 15 minutes to carefully read, interpret and summarize the feedback, which helped me to reflect. Last but not least due to sticky notes I didn’t miss any feedback, which happened quite often when doing verbal feedback rounds.

The only drawback I identified so far is that the written feedback can be easily misinterpreted and that there is no possibility to ask questions back. And of course you need to ask for a nice handwriting if you want to apply a happiness door.

Anyway, to put it in a nutshell the happiness door turned out to be a good feedback mechanism for me and there will be more happiness doors in my future training lessons for sure.

Why You Should Use a Definition of Ready in Your Projects

In my former blog post I introduced the concept of the “ready-ready backlog” for Agile teams. In this blog post I want to share some metrics about the effect of introducing a “Definition of Ready” (DoR) to industry projects.

I introduced the following DoR for an Agile team that has worked for 3 months together:

  • The business value of the user story is understood by the development team
  • The acceptance criteria are clearly defined and understood by the development team
  • Requirements on documentation, specification, configuration, test, regression tests and architecture are clarified
  • The development team has a concrete idea of demonstrating and testing the user story
  • The user story has been estimated by the team with a high confidence level

After introducing the DoR I gathered the following metrics from the following 7 sprints:

  • # of user stories committed for the sprint
  • # of user stories in the sprint backlog that did not fulfill the DoR
  • Velocity
  • Team happiness (1-10)
  • Fulfillment of sprint commitment (green = fulfilled, red = failed)

The results can be seen in the figure below:

DoR

 

By using the DoR in the backlog refinement meetings the behavior of the team changed perceptibly. Without the DoR it was sufficient for the team, if backlog items were shortly discussed and estimated. With the DoR the team focused much more on each backlog item and the discussions went deeper. More pitfalls were discovered upfront. Anyway it was hard to get each user story “ready” before sprint planning because of the high project pressure. After bumpy 4 sprints the ability of the team to analyze and refine backlog items improved significantly. For the following 3 sprints all committed user stories were “ready” according to the DoR and during the sprints less incidents happened due to overseen or miss-interpreted requirements. The DoR had a rather small impact on the ability to fulfill sprint commitments and velocity but by shifting the focus on getting backlog items “ready” it perceptibly improved the ability of the team to analyze and refine backlog items.

5 Tips on Getting Your Backlog Ready-Ready

Last year I worked with several teams on improving their development process by introducing a Definitions of Ready (DoR). Jeff Sutherland points out the importance of a DoR to achieve a “ready-ready” backlog in the following video:

 

Here are my six practical advices on getting a “ready-ready” backlog for  your projects:

Define your Definition of Ready:

Define your own Definition of Ready together with your team and product owner. The idealistic vision of a “ready-ready” user story is that the team can implement it without interruptions. Define your DoR according to this vision and your specific project needs. You can use the following list of questions as a guideline for your own DoR:

  • Does the user story meet the INVEST criteria?
  • Is the business value clear and understood by the team?
  • Are the acceptance criteria well-formulated and understood by the team?
  • Could everyone on the team test the user story?

Warning: I saw teams going way too far with their DoR, trying to lash requirements like in traditional design documents. Overcome the temptation to fall back in old habits.

Use your DoR for each user story:

Only the development team is allowed to call a user story “ready-ready”. Therefore the development team checks each user story, if it fulfills the criteria of your DoR or not. This can be done while backlog grooming or any time you prefer before sprint planning, but the product owner should be present.

Make “ready-ready” user stories visible:

It helps a lot if everyone can have a quick overview on how many user stories are “ready-ready” in the backlog. Use labels, coloring, traffic lights, prefixing or whatever you prefer to emphasize “ready-ready” user stories in your backlog. It doesn’t matter how you flag them as long as they are visible at one glance when looking at your backlog.

Make the sum of estimates of “ready-ready” user stories visible on your task board. Show the teams velocity next to it to signalize if you have enough user stories “ready-ready” for the next sprint planning. Having the figures prominent on the board makes everyone aware of the current backlog health and triggers action for backlog grooming.

Visualization of ready-ready backlog and velocity
Visualizing ready-ready backlog and team velocity on the task board

I also experimented visualizing “ready-ready” user stories on cards in a separate column on the task board but it was much more effort to maintain and update the column than just putting the sum of estimates on the board and the effect was the same.

Track open issues:

Make open issues (that prevent user stories from being “ready-ready”) transparent to everyone. It is crucial that open questions, unclear requirements, missing research or analysis, etc is visible to everyone, so that everyone knows what prevents a user story from being “ready-ready” and therefore needs to be resolved first. I my teams we keep track of open issues in a table that is attached to the user story like the one below:

Status Issue Responsible Solution
RESOLVED Is the address field mandatory for the user? PO Yes.
OPEN Check if email validation is already in place and working. Team

Live your DoR:

Make sure that the product owner and the development team understand the benefits of a “ready-ready” backlog. Provide your support whenever it is needed until the DoR flows through everyone’s veins. Live your DoR!

 

This Blog Will Change…

…to English!

I made this decision because I want to remove the nasty language barrier for all the potential international readers of my blog. I also hope to be able to reach more readers and trigger more discussions with this change.

No pros without cons…the drawbacks of writing in English (which is not my mother tongue) will be more mistakes (grammar, punctuation marks, prepositions,…) in my blog posts, but I promise that I will do my best to improve! 😉

Like always I welcome your feedback!

Stay tuned!

 

Meine erste Kudo Box

Eine der Ideen, die ich aus dem Management 3.0 Workshop mitgenommen habe, ist die Kudo Box. Ich habe vor zwei Wochen eine Kudo Box im Team-Büro aufgestellt und bereits erste Erfahrungen damit gesammelt.

In der letzten Sprint Retrospektive habe ich das Team gefragt, ob sie denn eine Kudo Box haben möchten – nach einer kurzen Erklärung lautete die Antwort kurz “JA”.

Ich habe die Box also an einem gut sichtbaren Ort neben dem Eingang aufgestellt, sodass jeder mehrmals pro Tag daran vorbei läuft. Die Kärtchen habe ich selbst ausgedruck und direkt neben die Box gelegt. Zum Selbstläufer wurde das Ganze allerdings anfangs nicht.

My First Kudo Box

Die ersten zwei Tage waren noch alle zurückhaltend mit den Kudos – ich habe dann begonnen die ersten zwei Kudo Karten einzuwerfen,  wodurch die initialen Hemmungen fielen und auch das restliche Team das “Tool” zu verwenden begann. Es folgten täglich weitere Kudos und es schien allen sichtlich Spass zu machen. Zeitweise war sogar ein echte “Kudo-Manie” ausgebrochen 😉

Kudo Card

In der folgenden Sprint Retrospektive habe ich die Kudos dann öffentlich verteilt. Es waren nach zwei Wochen über 20 Kudo Karten in der Box, was meine Erwartungen doch deutlich übertraf.

Wie groß der Impact der Kudo Box auf die “Team-Happiness” im letzten Sprint war läßt sich natürlich nicht eindeutig sagen. Subjektiv konnte ich aber eine sehr gute Stimmung im Team wahrnehmen. Die Ergebnisse der Sprint Retrospektive bestätigten dies auch:

retro

Die Kudo Box ist bei uns nun ein fixer Bestandteil und ich bin überzeugt, dass sie zur Team-Kultur bereits einen positiven Beitrag geleistet hat und noch leisten wird – bei uns war der positive Spirit und der Spass im letzten Sprint auf jeden Fall deutlich spührbar.

Es ist erstaunlich, aber als ich meine Kudo Karte(n) entgegennahm hatte ich tatsächlich dieses Gefühl der inneren Zufriedenheit. Meine Motivation wurde dadurch merklich positiv beeinflusst und ich denke da ging es nicht nur mir so. Ich finde die Kudo Box ist eine genial einfache Idee, die mir jetzt bereits ihre Praxistauglichkeit bewiesen hat.

Trotz aller positiven Effekte möchte ich natürlich kritisch bleiben und den Effekt der Kudo Box noch auf längere Sicht betrachten. Für die weitere Beobachtung finde ich vor allem die folgenden Fragen spannend:

  • Wie ist der Effekt auf das Team, wenn nicht immer jeder Kudos erhält, also manche Personen leer ausgehen?
  • Kann im Team ein Wettbewerb um Kudos entstehen?
  • Kommt es über die Zeit zu einer Kudo Inflation?

Habt ihr schon mehr Erfahrungen gemacht als ich und vielleicht schon Antworten auf die obigen Fragen gefunden?