The mandatory stuff

When I have a story writing workshop or some other brainstorming activity, one important task is of course to learn what is really important. Since I’m in the mental moving from scrum to Kanban, this has become more than important. It is crucial.

So, these are my phases of a story writing seminar:

 

The objective

During this part, we discuss the overall objective of the project. What we’re doing and why. I try not only to explain what the customer wants but I want the team to really make the objective theirs. I want them to form their own Commander’s intent so they not only know what the objective is but also what it’s not. We don’t have time for nice to haves. Most of the time…

 

Brain storming stories

This can be divided into a number of separate parts. If it’s a new group or the developers are not fully aware of the business, this should start with the discussion of the different user groups or personas.

Then we move over to the brainstorming of stories. Presented with the objectives and the user types, everyone gets to write their own stories. A tips here is not to push the user story format. When you make it mandatory, people will debate you, but if you instead say that you want to know not only what but why and for whom and that this is an excellent form for that, you get more in a story format. Don’t be afraid to see developers and operations as users. Some stuff you need for these groups too. And writing stories with yourself as user type makes developers learn how to use the format.

 

Grouping stories

After everyone has written their stories, I usually send two or three team members to the whiteboard to group the stories. I let them decide on groups.

After that we say the stories out loud. We select the stories we need, sometimes write some more and some of the stories are discarded after we explain why this is not necessary.

 

Highest priority

I then get everyone to mark on each story if it’s mandatory or not. Everyone get’s their saying.

We then sit down and I pick up the stories which at least one person said was mandatory. I then ask the following question about each and every story:

– If we don’t do this, the project will be worthless and unsuccessful?

This will make the number of mandatory stories much much smaller. When I was more junior as a product owner/project manager I thought the mere asking if the story was mandatory was enough. But the important question is if the story makes the difference between success and failure.

If a story is still considered as mandatory we look at the objective. And I ask the question:

– So, how will this help us reach the objective(s)?

A number of stories will lose their status as mandatory right there and then.

What is the first thing to do?

The next phase is to understand what we need to know where to start. If you have multiple sub groups, you should ask each group what they want to start with. Now the team often remember The Other Stuff, as development and testing environment, setting up build scripts and all that so be prepared for some extra story writing.

When every sub group has identified what they want to start with, they must say if they are dependent on another group to start with their first task.

If the groups depend on each other, use The Theory of Constraints to specify the priority. With that I mean that you should try to optimize the usage of the bottleneck resources.

Is this it?

This is an exercise which should be done regularly. As long as you have stories, you can focus on the next most prioritized items but you will need to go through all phases many times during a long project

The objective of the objective

Before I start a story writing seminar, I think it’s important that the participants know what is the purpose of the project and what is not the purpose of the project. I’ve never heard about a project where there is no deadline and money is not the issue. You must always focus on the right stuff to get the project to become a success.

So, what is a successful project? Well, I guess if it’s a project which meets the objectives. And to meet the objectives you need to complete the tasks which leads to forfilling that objective and you must probably try to spend as little time as possible on tasks which does not lead to the objective.

It is one thing to have someone tell you what the objective is. It’s a little better if you’re shown some kind of picture, but what ever the form; if an objective is just broadcasted to you, you might know it. But is it yours?

Mike Cohn has some interesting exercises for forming a project objective, but until today I hadn’t really grasped why I really found it so important that the team participate in these exercises and that you don’t simply tell the guys why we’re spending all this money.

When I presented the exercise, one of the guys frankly spoke out and asked why they were forming the objective and why the business folks didn’t do this. How were they supposed to know.

A very good question.

But when he said that it became so clear to me that what I really wanted was to know what they believed and thought. Everyone has their own picture and if they don’t tell what they think and believe, we cannot debate their idea.

So, out the window went the exercise and I simply asked everyone what they believed and thought. We listed all this input and then based on that we formed a simple Moore’s product vision for the project.

We then went back to the list and marked which items were mandatory to meet the objective and how they helped.

When we during the upcoming exercises formed user stories, we could really lean on those decisions. Both what was included and what was not.

One of the hardest tasks when you’re hosting a workshop is when people question your exercises. But if they cannot understand why they are used, you should probably not use just that one on that occasion. You should instead know what you wanted with the exercise and think if there is some other way you can reach that goal.

But the best thing is how much you learn about an exercise if they don’t go as planned. I’m even more confident in the relevance of a project objective, but the reason for formulating one in a story writing seminar must be clarified to the group.

Why user stories are not silly

I’m currently reading The Goal, an experience not unlike reading Godel, Escher, Bach in my youth or Sophie’s world a couple of years ago. Using the novel form to explain Business improvement (The Goal), Mathematics (GEB) or philosophy (Sophie’s world) seem like something impossible, but in these three cases the form (which, I grant, is only partly used in GEB) is truly successful. The reason is that the story format probably works well with human brains. It’s like it’s described in Made to Stick; by presenting a story, the information sticks better in our brain.

And yet, it doesn’t seem natural to even consider writing something so important in the novel form. It’s almost like if a subject is grave or important, the presentation should “fit” that. Perhaps this is also the reason for why so many question the user story format. Just the name is probably a hindrance.  Are we going to write “STORIES”. Are you going to gather all developers in a room and write stories. I guess the postits add to the kindergarten feeling most perhaps feel when presented with the user story idea in the first place. I mean, we need the developers to work (AKA, create code).

But stop and think. Like the main character in The Goal does. What’s the goal?

Well, the goal of every IT department should be the same as the rest of the company. And all companies must make money. Perhaps not today or tomorrow, but if you don’t make money, you will never survive.

OK. If the goal is to make money, what do you do next? Well, you should start moving in the direction of making that money. That does not mean that you should only focus on the things that bring in money now. That can, as you probably know, even make you lose money in the long run. Taking on customers who you can’t handle can cost you in the long run. Skipping that training for the developers can make them make simple mistakes. Etc. What is important is not taking the steps in the directions that doesn’t make you earn more money. OK, a company can of course participate in altruistic programs for help organizations, but this is just an exception. When you are at work your tasks should lead to your company making money.

But now the old lady has gone bananas. Starting with some strange books, moving over to user stories and now she’s rambling about making money. Where’s she going with all this?

If we now take that notion of making money down into the deepest corners of the developer’s department and sit down with Greg, the geekiest guy on the block. And we sit there and ask him – How will that piece of code make us make more money? What are the chances that he has no idea or worse; a false image? But why? Because some consider developers just working when they crunch code. That is what makes the company making money. If a developer is not crunching code, he’s not productive.

But what is a productive developer. Well that should be something like this:

Yes, there could also be something that could be disabled and then the two end boxes switch places, but the principle is the same. Now consider these two scenarios.

A: A user wants to do X in system Y and a change request is formed by him and the tasks are handed to a developer, who develops the functionality and delivers to the user.

B: A user wants to do X and discusses this with a developer. The developer informs the user that this functionality is already built into system Z and the user starts using that instead.

So, how was the productivity of the developer in these two scenarios?

How common do you think that this is. Or the scenarios where stuff is built more complicated than needed, or wrongly because something was misunderstood? Or the thousand other cases when the developer simply didn’t know what the user wanted and the user didn’t know his options. When presented with options (not too many but a handful) an intelligent user can often realize that he himself didn’t know what he wanted either.

So, how can we best inject the knowledge into the developer? Well, giving him that specification is a clear path to failure. And in the case of our two scenarios, the specification in itself was waste since it was never needed in the first place.

What we need are more stories. So, is it enough just to use the user story format and give the developers that bunch of story cards?

Have you seen the Dead Parrot sketch by Monty Python? When the sketch was first presented to BBC, they simply wrote down the dialog but no one could see the joke (well, perhaps you don’t like Monty and then it’s never funny) and it wasn’t until they played the stuff the greatness was spotted. And it’s the same with user stories. The actual text is just a reminder, it’s the forming of the story which brings value. Remember that the objective is making money and if we can do that without writing any code at all, we can spend that time on something else. But to enable this, we must use the competence of the developers and the business people at its maximum. And user story workshops are an excellent tool.

TFS 2010 for us product owners

I’m currently using a lot of Microsoft Project to keep my distributed stakeholders updated since the scrum dashboard just works for the current sprint and the 2008 web access isn’t very… accessible.  The stakeholders can’t get the overview they need. So, I spend time on separate Microsoft Project files with the long term plans (as described in a previous post) and I keep the product backlog in TFS.

So, I was just thrilled by the images on BHarry’s blog, describing the new features for us non programmers. Finally, I can really invite my stakeholders to keep themselves updated on the level they need.

The dashboard looks awesome! Here are two examples:

For me as a product owner, I of course long for the hierarchical work items:

If I still want to show Gantt charts, I can (if all goes well) use the upgraded Project Integration, since it conserves the hierarchy. This is the main reason I don’t use the integration today.

I’m also very curious about the Sprint planning functions

So, what more can I say: JUST BRING IT ON!

Why stories are so important

Sometimes you read books which has a profound effect on how you view the world, what you do and why you do stuff. Sometimes they can change the way you work, sometimes they make you understand why you do stuff the way you do. But the most interesting moment is when you’ve read a couple of books and their collective intelligence makes sense together. I just had one of these moments, finishing Made To Stick, which I’ve already mentioned here on this blog. The book is worth the read. Many times over. There are so many interesting things but one of the most breathtaking was the rule about the story. The reasons for this being of such importance to me is that it brings together Lance Armstrong with Mike Cohn. Isn’t that just amazing. Now, it’s not like Cohn has ever been part of Armstrong’s team or something. But still, here goes!

The authors state that one of the success factors of a message is that it contains a story. In the case of Lance Armstrong, what makes him so interesting? I posted the other day some Nike commericals with Lance Armstrong and they both reflects on parts of the Lance Armstrong story. Yes, he’s one of the most amazing cyclists in the world. But what makes it unique is that he,  the son of a single 16-year-old mother who busted her ass to make her son forfill his dreams to become a cyclist, became a world champion.  And when he was on top, he got cancer, less than 10 percent chance to survive. But he did and became the best rider in the world and a champion for the cancer cause. What a story! If you view the Nike adds with Armstrong you can see that they all play on him being all the time on the bike, pushing the limits all the time. He goes out in the morning, cycles through rain and comes home in the middle of the night. He goes through all those procedures. But he also takes the time to raise his hand to those cancer sick kids in the hospitals. The power lies in the stories. The commericals can be kept short because when you see them, you have the Armstrong story in your memory.

No wonder that Mike Cohn talks about user stories. Both words are important. There is a person and there is a story to be told. No wonder that the "Based on a true story" books are so popular. People like when there is some truth to a story.

Mike Cohn says that a user story is a place holder for a discussion and if you look at the Nike commercials, you can see the power of a story. You get context. You get emotions and you get a really sticky message. But one should not forget that all stories are not interesting and sticky. Just because you use the user story format (As a [user], I can [function] so that [reason]) doesn’t make it sticky and interesting.

Despite Armstrong’s long career, one moment has stuck in most cycling fans mind. The year is 2001. We call it The Look. His long time antagonist had been strong and Armstrong was sitting in the middle of the peloton all day. Not like him at all, so most thought he had a weak day. It’s the final climb of the stage. Alpe D’Huez. You can see in the film what kind of climb it is. But suddenly he’s in front and there is The Look. Armstrong looks at the face of his antagonist and the rest is cycling history. What a story! (And now I’m going to you rest from Armstrong stories for a while)