Blog Posts

 (Originally written by Thomas Botton and Benoît Pointet for the Scrum Alliance and posted at www.scrumalliance.org/articles/380-key-dimensions-of-user-stories)

Dealing with a large amount of user stories (more than your fingers and toes can account for) is not easy, most often they sit one after the other in your product backlog, or they are shuffled on a story map. Dealing with user stories is basically projecting them in a space of dimensions. The three essential dimensions to our scrum process at Liip are: the backlog order, the complexity (we call it effort), and the business value. Let's review briefly the first two and then focus on the third one.

Backlog absolute order

The product backlog order represents the urgency of a story. The absolute ordering forces the client to refine his understanding of the product backlog: there's only one single most important story to do next.

Story points

The complexity, is an integer value from the Fibonacci series, which represents a mix of technical complexity, work time, and even uncertainty bound to a story. Developers agree on it through the estimation poker game. Those two dimensions are commonly used in scrum teams around the world. The third one, business value, not so much.

Business value

Why isn't the business value that much used? Probably because scrum masters tend to forgive more to POs than to developers and because POs don't see the need to express this value. But business value matters - to everyone in the team. Even more, business value represents something that's deeper than the reason of the user story, something laying deep into the business logic: the added value that the story brings to the business.

But that's so hard to express. Really? Really harder than estimating the complexity of a story? Think twice! Or rather, think the same: complexity estimation is relative and summative. Business value estimation should be the same: estimate the value of a story relatively to the others, and resume this value in a single number.

You got it! We do estimate business value the same way the developers are estimating the complexity. We ask the PO and stakeholders to play estimation poker – and they love it! It's a unique opportunity for them to get together and come up with an agreement on story relative values.

Applying the same rules on estimating business value and complexity has an important side-effect: it brings understanding and respect in the project team. A PO will be more likely to understand why some stories need to be reestimated by the developers - and vice versa. Using a numerical scale for the business value also allows to visualize it (cf. chart below), something MoSCoW can offer in a limited way - if at all.

As an example, here's such a chart for the stories of sprint 1 (green), sprint 2 (blue), and the remaining of the product backlog (grey) of a small project we started recently. You clearly understand that stories laying at the top-left corner are the most interesting, which is why we took them in our first sprint.

The ROI (a.k.a Return On Investment)

Such a chart brings to your scrumish minds a sense of "Return On Investment": the ratio between the business value and the complexity (aka. BV/SP). Since both are relative metrics, this is a relative return on investment that you'll never be able to translate into dollars, but which allows you to compare user stories. On the following chart, ROI is increasing in an angular way. It is now fairly easy to spot the undone stories (grey) with high ROI: 8, 20 and 30. Those are probably the ones that the PO will put at the top of his product backlog.

Those three dimensions are very flexible until sprint commitment. However, right before it, both the complexity and the business value must have been estimated for the top of the product backlog, which means that the product backlog has been re-ordered! The classical sprint commitment can then occur: the team pulls the stories from the top of the product backlog into the sprint backlog, negotiating order and amount with the PO. After commitment on a story, both its complexity and business value should not be altered, since it would tweak the metrics.

Last week I presented Scrum@liip to a very interested audience. 40 people at 8am was really impressive. It was great to see how people feel that we really pushed Scrum to a very high level. Even if we sometimes feel that we could do even more and faster. But all is very relative... below an extended version in German. Here you get to the slides.

Die Einladung von Peter Stevens zum Thema "Scrum in der Firmen-DNA" habe ich gerne angenommen und letzte Woche gut gestaunt, morgens um 8h rund 40 Interessierte in der Industrieperipherie von Zürich anzutreffen. Offenbar hat das Thema viele angesprochen, denn entsprechend war auch der Austausch, der bis Mittag in hoher Intensität angedauert hat.

In der eigenen kleinen Welt kommt manchmal das Gefühl auf, mit den angestrebten Anpassungen - die natürlich nie aufhören - an Ort und Stelle zu treten. Macht man dann bei Gelegenheit einen guten Schritt zurück und präsentiert den aktuellen Stand einem interessierten Publikum wird deutlich, zu welcher "Güte" wir Scrum bei Liip mittlerweile getrieben haben. So ist das konsequente Besetzen aller Rollen ohne Personalunion heute selbstverständlich, die Methode innerhalb der Firma absolut unbestritten und die Zusammenarbeit mit dem Kunden transparenter denn je.

Feste Teams mit etabliertem Flow und beständiger Velocity und die Konzentration auf Business Value befähigen uns heute, Projekte von Beginn mit maximiertem ROI (Return On Investment) anzupeilen. Mit traditionellen Methoden ein Ding der Unmöglichkeit.  Dazu notwendig ist aber auch eine Firmenkultur, die den Umgang mit jedem Individuum im Sinne einer Meritokratie und nicht verlockend herkömmlich als Hierarchie lebt. Viel davon ist wohl durch unser langjähriges Open Source Engagement sowieso fest verankert.

So freut natürlich die Einschätzung von Peter, die kaum völlig falsch sein wird:

"My first external training and coaching customer was Liip AG. I gave them their first introduction to Scrum back in 2007, and helped them with some additional training and retrospectives over the years. In no company have I done less and seen more come of it than at Liip (my suspicion is that they already had Scrum Values in their DNA). In any case, they are growing rapidly and organically while going from one Master of Swiss Web to the next."

Und hier noch die - nicht ganz Corporate Design kompatiblen - Slides.

Two weeks ago, the first edition of the Agile Tour Lausanne took place. Luckily, Liip proposed me to sponsor some of my working time in order to prepare it.

It was the first conference I ever organized and I must say that if you are interested in doing something similar, just go for it! It is really a great experience!

Thanks to my co-organizers Yann Lugrin, Jonas Vonlanthen and Frédéric Noyer, we managed to get more than 60 attendees - which was beyond our expectations.

The Agile Tour organization

As introduced on its website, the Agile Tour organization aims to "massively communicate about Agile, share their visions of Agile, federate and support people and local businesses in regions" once a year during October and November, all around the world.

Each event is self-organized and should involve as many local people (organizers, speakers, attendees) as possible; the goal to keep in mind being to "create leaderships" in a lot of regions of the world in order to "impact the professional world".

The last part of the previous sentence is the most meaningful to me as it's exactly what we try to achieve every day at Liip.

In Switzerland, Lausanne is the third city organizing such an event - after Sierre and Geneva. Nevertheless, we thought there was enough space between Sierre and Lausanne to not overlap too much and also because the Agile Tour is not about competition, but about acting as a community.

In that spirit, we were even coached by the already existing Agile Tour Sierre team (thanks again Jean-Pierre Rey!) to benefit from their experience.

The conference - a short summary

We prepared the day so that it was mainly focused on real world experience feedbacks of Agile practices, and more specifically Scrum.

As we were expecting part of the attendees not having any background knowledge about the Agile topic, we decided to start the day with theoretical presentations.

It was a very good choice because it created a common knowledge basis for the following discussions which happened during lunch and coffee breaks.

Then in the afternoon, we organized talks showing real use cases. Companies like jobup.ch, l'Etat de Genève and Liip presented how they deal with Agility in their daily business.

If you weren't able to join us, you can easily go through the speaker slides that you can find on the Agile Tour Lausanne website.

The conference - follow-up

As the attendees know, we asked all the participants to fill an evaluation form in order to gather feedbacks.

Hence, we will have soon our retrospective (an Agile event has no choice but to use Scrum itself) to check what people thought of their day and see how we can improve - and maybe an Agile Tour Lausanne 2012 will be announced afterwards.

I'm just back from the J.Boye Web and Intranet conference in Aarhus, Denmark. I went there to participate in the IKS Semantics UX contest that I had the honor to win. This invitation gave me a great opportunity to be a part of this unique conference. I would like to spend some time to share my thoughts with you on it.

The conference

Why is this conference unique? Because it focuses on the Web and Intranet from a user perspective. It is the perfect place for large organization members to share experiences, ask questions openly and discuss a broad range of themes that varies from going mobile to health oriented intranets. The talks were thus not really made for me and as much as I found them clear and well presented, they didn't rock my world. But that's fine, because I'm not the target audience and it's also my professional responsibility to be informed and on the front of the wave. On the other hand and as you can imagine, being a vendor in the middle of all these users was really great.

The social aspect

I didn't try to pitch for Liip so much because it was clear that this went against the spirit of the conference. What I tried to do was to be as open as the rest of the crowd and try to participate and help answering some questions and problems that most of web project managers, social strategists and intranet managers have. The effect has been tremendous, I ended up having enlightening and rich discussions on many different aspects of the business I'm in. I was surprised and astonished to see how much Liip and my professional experiences generally seemed to interest and impress others a lot. I heard many times "Oh really, and I thought there was no way to get this done...".

Conclusions

Here is a small list of some conclusion I could make after so many discussions.

On Mobile strategies:  Niwea is the trend governments and large corporations adopts for their intranet strategies.

On User Experience practices: Doing the workshops that Liip does (the 5S model) and integrating the UX process into SCRUM clearly appealed to the people.

On CMSs: Decoupled components and going away from a monolitic block is the future of CMS, open or not. We try to reach that with Symfony CMF

On project management: Successful project with SCRUM were common contrary to more traditional approaches that brought mostly cost explosions and years late delivered projects. 

I have more examples but what I would like to share here is that this conference has been an incredible chance to get a strong validation that Liip has a great strategy. It's difficult to phrase the overwhelming feeling that I constantly felt during the conference. Liip is doing the right thing, answering real needs and in the perfect way. The best part is that's it's not me saying this, it's the sum of validation I brought back with me.

On top of that I met some really great folks, inspiring, sometime challenging, always interesting and extremely open. This openness is the main speciality of the conference and make it totally worth it. It's my take home message. Be open minded, don't close yourself in a mentality and keep listening to other, there is everything to win doing that!

Last week, we had a Scrum Workshop Day at Liip's Fribourg office. For the first presentation of the morning, I introduced the group to the Happiness Metric. We all had a go, and talked about what makes us happy and what not.

The Happiness Metric is a tool for agile teams to find out how everyone feels about the company and the work they are currently involved in. The metric over time shows how the team is doing and how it has evolved. At Liip we care about the happiness and well-being of our employees, and we always try to remember that work should also be fun. Talking about happiness in a structured way seems to be a good thing, so the interest to get to know the method was high among Liipers.

Jeff Sutherland introduced the Happiness Metric to me in a talk he gave at a TriFork GOTO Night in Zurich this last March. Jeff specifically referred to the practices of the Swedish company Crisp. He pointed to the blog post where Henrik Kniberg of Crisp talks about how he uses the Happiness Metric "as the primary metric to drive his company".

The 4 questions of the Happiness Metric

Basically, for the Happiness Metric each team member answers four questions.

• How happy are you with your company? (scale 1-5)
• What feels best right now?
• What feels worst right now?
• What would increase your happiness index?

For our first trial of the Happiness Metric, I chose a quarterly retrospective, a meeting each scrum team has four times a year to discuss team issues, strengths and weakness in order to set goals and identify improvements. Normally, a member of Liip management attends those team retrospectives, so it seemed to be a perfect opportunity to let the management know how people feel about the company.

Since we are all familiar with sticky notes in agile teams I suggested we write the answers on Post-it notes and stick them on the wall, each member in turn. Whoever felt like doing so could also give a short comment on his or her answers. For issues that came up multiple times, we raised a team impediment in the impediment backlog. We agreed to take immediate action when any person's happiness number fell below a two. In some cases it it might have been necessary for the Scrum Master to talk with someone 1-to-1 to find out whether the matter was too personal to be shared with the team.

It is still the subject of debate whether it would be best to ask for the Happiness Metric in the beginning of a team retrospective or at the end. If you ask about happiness at the beginning of the retrospective, team members might tend to give a low happiness index for unspoken issues. After the retrospective, when those issues were discussed in a solution-oriented way, the happiness index might tend to be higher. Also we couldn't decide whether it is better to start or to end the meeting in a more personal mood compared to the issue-oriented discussion of the regular retrospective.

We are not as advanced with the Happiness Metric as Crisp is yet. We aren't using the metric with everyone in the company. We don't report the answers in a spreadsheet. Also we don't ask each employee to update the index every month. These are options we will explore to find out what makes sense for our teams. Management was clear during the workshop about how important it is for them to have happy employees at Liip. They want to know how people feel at work. Therefore, the Happiness Metric might well find a place in our company's agile toolbox.

All you need to start an agile project are two things: a vision and a backlog of things to build during the first few weeks. In many cases these things are represented as user stories. It is the product owner's (PO) or product manager's (PM) task to keep that backlog in order: Writing new user stories, prioritising and re-prioritising them and disposing of them when they become obsolete.

There's a number of ways to structure a backlog. A common one, that I'm currently using, is having sprint backlogs for the current and a few upcoming iterations, plus one big flat product backlog where all stories go that aren't scheduled for a particular sprint. Another one would be something called *Story Maps*. I haven't used them, but here's what I've learned about them during an OpenSpace session at the fabulous Agile Lean Europe 2011 Unconference in Berlin (and in a little bit of reading, particularly Jeff Pattons blog post about it).

Everything starts with the vision, it lets you set your goals, the first order structure of your project. Each goal is usually associated with a number of personas – fictive prototypical users of the functionalities. For each persona you will find a number of things they will want to or have to do. A management summary of each of these things will go into what is often called an epic user story (or just epic).

What's described in an epic is usually way too big to be estimated and implemented. Suppose one of your personas, Helmut, a photographer, needs to edit his photos after upload to your service. Here's your epic. It needs to be broken down into User Stories that adhere to the INVEST criteria, which stands for Independent, Negotiable, Valuable, Estimatable, Small, Testable.

But before you start writing those user stories, think of the individual features needed to make up your epic's functionality. Maybe the photographer needs to do color correction, shape the image (rotate, crop, resize), and so on. Once you think you've found them all the time has finally come to write the user stories.

Thanks to the structure in place by this time, it should be fairly easy to come up with the stories needed to build the features of your epic. While the "brain-storming" approach I've been using so far fails to give any hints on whether your set of stories is complete or not the fine-grained separation at feature-level should make any omissions obvious.

In order to further support this, and to also come up with a sensible priority order, stories in story maps are each assigned one of three levels of importance: Walking Skelton, For Go-Live, and Wow!

Assign a story the Walking Skeleton label if you think it is needed to get the most basic implementation of the feature you can think of to work. For Go-Live means: without this story I wouldn't bother to release this feature to any customers. Last there's Wow! – these stories will please your customers and, possibly, give your service an edge over the competition. Probably some of these will never be implemented because their priority is too low and you decide to ship your new functionality without them.

This brings me to a couple of questions that I will have to leave open for further investigation, and a few more that were raised during a workshop day yesterday at Liip: Should I dispose of an epic only when it is completely implemented? Should I drop any Wow! stories in it once I decide to ship it before they're implemented? Or would it make sense to keep them in a backlog, along with the epic to which they belong (even though that's been mostly implemented)? Or should I create a new epic (e. g. "Improved Image Manipulation") and assign my leftover stories to it—and would they belong to the Walking Skeleton of that new epic? Should stories from different epics be done in the same sprint, and how will we prioritise them? And last, but not least: How do we do this practically with our customers, especially in ongoing projects?

We're going to elaborate on these questions during the next few weeks. Please share your thoughts if you're already using Story Maps.

On Thursday the 19th of May I attended the "Hermes Forum 2011" in Berne and I got some interesting insights in how you can combine a rather linear project management approach with an agile methodology like SCRUM. And even more interesting: It has been done successfully.The following ideas are based on two talks. Thanks to Oliver Gut from Erni and Dr. Christoph Streit (bit.admin.ch) for the interesting input.

HERMES an ancient greek god and the way Swiss government is managing their projects

Swiss Government has chosen a somehow divine approach to manage their projects. To make it short: a quote from the official website of the Swiss government: "HERMES is an open method for the uniform and structured management of projects in Information and Communication Technologies (ICT). The method is mandatory within the federal Administration for all ICT projects. HERMES is also used by other public administrations, universities and businesses."[source...]

What you need to know about Hermes for now

I will skip a deep introduction into HERMES in this blog post. For the interested among you: There is a quiet handy summary of the method available for free download [here...]. The following dense and short introduction is based on the same paper.

Embedded and Enriched Process

HERMES can be considered as a method for process support. Projects are divided into phases (grey), embedded into support, controlling and management environments (pink) and the processes itself are enriched with supporting sub-models (green) (eg. risk management, quality assurance, and so on….). As last element procedure models (blue) give the structure for specific activities and methods within a sub-type of a project type: E.g. the development (project type) of a commercial application (subtype 1) or an application for office automation (subtype 2) may vary.

All roles, activities, decision points of the three elements (Process structure, sub models and procedure models) will form the final WBS (Work-Breakdown Structure) that is individualized for each project.

And where to put SCRUM?

An introduction to SCRUM can be found here. To be shorter this time: SCRUM fits in the Implementation Process of HERMES.

Cosequences of the integration

The activities from the procedure models and sub-models must be taken into account. Possible solution: include them into the product backlog. The Sprints must be respected as a time-frame within the implementation phase of the HERMES project. Within this time-frame SCRUM makes the rules. The SCRUM artifacts can enrich the reporting for the HERMES project controlling.

Conclusion

SCRUM and HERMES have a common goal: Transparent and well structured projects in order to present a good result within the deadlines without wasting resources. As SCRUM is a de facto standard for managing modern IT projects and more and more developers get used to work with this agile method it fits well in the HERMES Framework. And there are benefits for both methods: SCRUM can be embedded into an enterprise quality and risk management process. HERMES can use the agility of SCRUM in order to get even better project results.

Last week I had the opportunity to talk about User Centered Design and Agile at the annual Italian phpDay that was held in Verona (more on my talk further down). It was my third time at the conference and it was a pleasure to see how much it had grown. It is organised by the GRUSP, the Italian PHP user group that is at the heart of a growing, dedicated and passionate PHP community. Many of the attending developers are part of small companies and most of them had to go through quite a rough patch in the previous years, facing a grim crisis and stagnant economy. So I was very curious to catch up and very happy to see that the situation seems to be getting better, slowly but still. Not only has unemployment started to drop, but revenues are slowly recuperating. Most important though is the development of the perception of PHP as a means of development: While two years back Italian companies would still put a very sticky "script-kiddie" label on PHP-developers, things are turning to the better. Definitely also in part an achievement of all the networking efforts of the GRUSP.

This years edition of the phpDay felt definitely very international, with a lot of top notch speakers from all over the world. Plus a whole delegation of Liipers, yay! The organisers did a good job in mixing speakers: some international and some local, some known and some new.
One very cool addition was, that the phpDay was part of a double conference together with the jsDay, dedicated, surprise surprise, to javascript. JsDay had started a day before phpDay and would overlap for one day. In the past few years the phpDay always featured talks on javascript, and the interest of the frontend community had grown so big that it totally made sense to have a separate mini-conference that people could choose to attend solely. When I heard about the split I was a bit afraid that the segregation would do more harm than good, but actually what happened was the opposite: no segregation, instead the day with overlapping conferences really brought together a cool mix of people.

As always at conferences speakers get the extra treatment, which in the case of phpDay means a great speakers dinner with awesome food and fun people. A blast!

From left to right: Kore Nordmann, Thijs Feryn, David Zuelke, Juozas Kaziukenas, Eric Kort, Helgi Thorbjoernsson, Christian Schaefer

UCD & AGILE: The long and winding road of change

The topic of the talk I gave this year has been keeping me going for quite some time now: How can we integrate User Centered Design best practices with Agile Development? While three months ago I had the impression to know it all, four weeks ago I was a mess. Nothing I tried had really worked, all the concepts we had figured out looked good on paper but not in practice and most of all: the impression to miss out on some detail that would help in letting fall the tiny pieces of our ideas into place. At that time I went to another conference, UX London, and was lucky enough to attend a workshop on UX Leadership held by Kim Goodwin. To my surprise she spoke about change management and what it takes to bring a new way of thinking and working into a company: involvement - on all levels an with all means possible.
I left UX London in a state of shock. But I was also immensely inspired and immediately started a completely different strategy of involving developers and product owners with us UX people and thus getting back into the loops of the projects - with amazing results.

This talk describes what I think are the fundamental elements that shape a successful integration of UCD and Agile.

The talk was extraordinarily well received, it was an honor to give it and i am absolutely blown away by the awesome feedback I got. Thanks for attending!

Pierre here. After getting my Scrum Master Certification with Danube I was eager to move the scrum artifacts from the digital to the actual physical space. I had this fantastic plan to build a wooden mobile scrum board. One that would look nice and we could take into our different scrum meetings.

On my first attempt to realize this plan, the shop was closed. Bummer! I had forgotten that most shops were closed on Monday mornings. On my next attempt, the shop didn't carry the type of light yet nice looking wood I had envisioned for our board. After finally finding a shop with the right type of wood, it didn't offer the right size. That is when I remembered Jimi Fosdick's words. He was our scrum trainer and told us that we needed nothing but some painter's masking tape and Post-It notes in order to get started. He said: "It doesn't matter how it looks! What's important is that you actually do it! And there is no excuse for not doing it!"

I bought the tape in a do-it shop around the corner. Back in the office, a nice and clean white wall in the our Liip lounge seemed like the perfect spot for our scrum board. Within five minutes the whole thing was set up.

1. The team met on the sofa.
2. We planned a sprint.
3. We started working.
4. It was that easy!

When we were fourth day, our sprint burn down chart actually went down for the first time. On the same day, we had our office-wide team meeting in the lounge and unfortunately the projector was making usage of the exact same wall we chose for our board and charts.

So we tore the whole board down and started looking for a better spot to let the scrum artifacts live. That's when someone noticed a tiny blackboard. It was located just besides a door and didn't offer any space to sit around it. I guess this is why to that day, no one had ever used it. But it was perfect for our daily standup meetings. Using different colors of chalk, we drew our Scrum Board on the blackboard and set up the sprint burn down chart using the tape.

This is how a roll of tape and some Post-It notes changed our everyday lives at work. We have been using this board over the last three months. To this day, no one has expressed any regrets about going physical with the scrum artifacts. On the contrary, we feel even more in control of our sprints. And sure, for when things are distributed and need to be online we still do use the amazing Greenhopper.

So what are your experiences with physical vs. virtual scrum boards?