Prioritizing User Stories

One of the most important survey results conducted by an important international organization, states that 64% of the functionalities included in software products are never or almost never used!
How come?!?
One way to avoid such a waste of resources, is to assign priorities to the user stories and to develop them starting from the highest.

 This post wants to address that 64% of features to be developed, which are never used by the final users once the product is deployed on production. After all, avoiding those features isn’t a way to reduce costs and time necessary to go live?

Let’s see how SCRUM faces to this issue.
As you probably know, the SCRUM framework provides three different roles: the team, the scrum master (SM) and the product owner (PO) (see URL). All of them are important. Maybe the team can be considered the most important, but for sure, SCRUM cannot work if any of those is missing.

This post is dedicated to the important role of the Product Owner and to one of its duties: prioritizing the features!

Once the gathering requirements phase is finished, the product owner should have in her hands a list of index/note cards in which are written the user stories.

The process of prioritization, must be conducted in order to:

1. Maximize and accelerate the ROI
2. Reduce risks

In order to maximize te ROI, the PO must have a clear understanding of what the customer wants in terms of: objectives, necessities, opportunities to reach, in one word, she must understand what is the actual Customer Business Value to gather.

Reducing risks, on the other hand, is primarily a matter of:

• Remove any impediments
• Give answers and explanations to any doubts or open points
• Deepen, if necessary, user stories that are not clear
• Execute as soon as possible any critical project activities

We can consider critical, an activity that will use a new technology not yet known to the team.
Or, furthermore, an activity that is one of the most important of the entire product, over which there are lot of expectations from the project stakeholders.

For the first case mentioned (new technology) is important to work on that feature as soon as possibile in order to “understand” the new technology and how to work with it. This will allow the team to capitalize the knowledge just acquired and will lower the risks.

Facing the second case (hot feature), it is again a matter of work quickly on it and to fast deliver it in order to receive, even here as soon as possible, feedback from the stakeholders.

Thus, it’s only a matter of assigning the right priorities, isnt’ it?! Yes but, how?

Actually, there are many methods available to achieve that goal, but the one I want to explore today, is the one that takes care of the customer business value and the risks associated to each feature, assigning to them an index (from 1 to 10 for example) in order to draw a point in a x/y graph.

This method is also mentioned in one of Mike Cohn’s books (Agile Estimating and Planning) that I strongly suggest to read.

So, let’s use Excel.

Create a new worksheet containing three columns: User story ID (or title), Business Value Index, Risk Index.

List all the user stories and for each one first assign a business value index: 1 for the lowest and 10 for the highest.
Higher values should be assigned to each activity that directly aims to one or more of the objectives to be achieved.
Lower values should be assigned to the activities not so important in achieving the goals like ancillary activites, maintenance or administrative activities, reports, etc.

Once a business value index is assigned for each feature, is time to provide risk indexes.
Higher values should be assigned to critical features like those that uses new technologies, those not well described or well understood, those that have  many interactions with external systems, those that will serve different typology of users and so on.
Lower values should be assigned to the remaining acitivities.

Now it’s time to create a graph, having excel plotting the points.

Now, compare the graph you obtained with the reference matrix above reported.

Well, it is time to start working and remember: the features never or almost never used, are the ones having a lower business value assigned; so, do them at the end and, furthermore, try to avoid those with an high risk associated!

Next Agile Course Dates

Hi everybody!

This post to inform about my next two agile courses organized by the European School of Project Management, for the next October (see below the details).

Title: Let’s SCRUM
Duration: 2 days (2011 October, 6th and 7th)
Place: Collegno (TO)
URL: http://www.espm.eu/index.php/it/corsi/catalogo-corsi/metodi/details/88-corso-scrum

Title: Agile Project Management
Duration: 1 day  (2011 October, 10th)
Place: Milan
URL: http://www.espm.eu/index.php/it/corsi/catalogo-corsi/metodi/details/87-agile-project-management

Playing Collaborative Games

It often happens that I teach in IT and project management courses.
What I’ve experienced is that one the of hardest thing to do in those situations, is to maintain high the level of interest and concentration of the attendees, allowing them to gather the greatest benefit from the course itself.
Actually there’s a secret…let them play!

On january I was in Scotland to attend to the SCRUM Master Certification Training Course.

In that occasion Simon, the trainer, organized some interesting games where the attendees, me included, were physically involved.
As usualy happens we were initially reluctant, but once the ice was broken the involvement of each one was really high, as well as the enthusiasm for the results.

Another occasion during which the collaborative games were used as training tools, was during the Italian Agile Coach Camp in Umbria. Unfortunately, I did not participate to those games because contemporarily there were other interesting tracks and I could not avoid to participate; it was really a pitty!

But, lucky me, we had retrospectives about those game sessions and I had the possibility to understand the actual worth of doing those games.

Both the two occasions were triggers for me. They helped me to deeply understand what such a powerful tool the collaborative games is!

Why?!?

1. First of all, they are games. People love to play games, even more if their company pays for it!
2. Second, players have still to pay for playing: you pay, leaving your comfortable zone and putting yourself into a new situation.
3. Third, the attendee is physically, not only mentally, involved. This helps the process of learning and facilitates the brain to store and consequently to remember and recover it.
4. Fourth, is a stimulus for the attendee to immediately activate the passive knowledge s/he has just learnt listening to the trainer.
5. Fifth, a game establishes a cheerful environment and creates a team building effect.

In other words, playing games help us to better understand because of the short feedback cycle (it sounds familiar, doesn’t it?).

Playing collaborative games is a quite sure way to energize the attendees, having them concentrated during the entire course. Which games I used to play in my courses?

A must game is the penny game, but also the specifiers and doers game using a set of role cards to introduce biases or, again, the alphabet games to consolidate what was learnt and the planning poker game.

Furthermore, I also use information radiators such as whiteboards, flipcharts, note cards stuck on the walls,  a task kanban board that shows the progress of each topic of the course, which helps the attendees to see progresses.

The big elephant in the room

“Elephant in the room” is an English metaphorical idiom for an obvious truth that is being ignored or goes unaddressed. The idiomatic expression also applies to an obvious problem or risk no one wants to discuss. It is based on the idea that an elephant in a room would be impossible to overlook; thus, people in the room who pretend the elephant is not there have chosen to avoid dealing with the looming big issue. (Wikipedia)

During the last weeks I have given some training sessions regarding project management topics (gathering user stories, planning, estimating, communicating, etc.). What I did, and in some cases what was explicitly asked for by the clients, was to speak about those topics from a traditional point of view as well as the agile one (Might I lose the opportunity to talk about agile?!).

Well, the courses were done for big organizations such as banks, assurances and a multinational that produces energy and it happened that when we have finished to analyze the two different approaches, it was clear to all the attendees that in some situations (telling the truth the most of them) the agile approach in planning, estimating, communicating and conducting the project, would be definitively the best one.

Indeed, some of the attendees exasperated by the problems they encountered, said that they already have tried to embrace agility, changing their approach in estimating activities, trying to be more adaptable in managing the changes and fostering the collaboration between all the parties involved in the project, but, systematically, they had to give up, due to problems and frictions with other colleagues.

People, most of the times, don’t want to change.

They do not want to change approaches, mental schemas, “habits”, because this implies:

• an effort that they don’t want to pay
• they do not want to leave their “lovely” comfort zone
• they have fear to loose power or control

Surprisingly, this happens even if it is clear to all that they have big problems in managing projects, even if they know they cannot face to projects’ changes smoothly, even if they know they cannot be more productive, faster and cannot improve the overall quality of their products, without a change.

They pretend not to see, the big elephant they have in front of them, which is staring at them, a bit embarrassed, trying not to move too much.

That problem is even more bigger, if the people who deny the existence of such an elephant, are the managers, the bosses, the decision makers.
The employees, after some trials in convincing them, could give up, surrendering to such a strong resistance.

This situation is a catastrophe for each of the parties.
The employees stop working assertively.
The boss looses the esteem of his/her colleagues and a great opportunity to improve the overall performances.
And, finally, the whole company, soon or later, will lose the most talented people, because for sure, they will not accept for a long time, such a frustrating situation: instead of being considered worthwhile “change agents”, the company treats them as annoying people.

Better SW Conference Late Reflections

Even if with a delay of some days, here I’m with a short, short summary of the Better Software Conference which I attended the last week.
It was amazing!

Firstly because I had the chance to meet again some of the people I knew in Umbria at the Agile Coach Camp and which I’m going to meet in Berlin on the next september for the Agile Lean Europe 2011 #ALE2011 un-conference.
Secondly, beacuse that day has been a great source of news, hints, tips, tricks, suggestions…waht do you want more from a conference?! Frankly speaking, I do not think is possible.

By the way, I would share with you some of the points I consider the most important.

The conference was an occasion to put myself out of the usual working routine and to dedicate time to listen, observe, learn, think and to reason about it.
And, not secondary, I’ve consolidated many certainties, definitively abandoned some doubts and I’ve definitively sorted my personal strenghts and weaknesses in relation to the agile world.

Actually, what I’ve figured out is about…..

How to arrange the war-room (as the PMBOK states “the room where the pm team work”) in an agile way. Using a lot of information radiators favouring the osmotic communication, creating dedicated areas such as the “Thinking Area”, giving to the team the possibility to personalize the environment.

How important is choose the right metrics when measuring your and the team work.

How important is to be completely focused on the present, avoiding multi-tasking, reducing the WIP, the queues and learning from the following statement: “Stop Starting, Start Finishing”

How wise is to remind what the agile manifesto states regarding the sustainable working pace and the hints to preseve a 10% of time in your sprint backlog, to give the possibilities to the team to learn or study or, in the worst case, to manage any urgencies or refactoring activities to reduce any technical debts.

How myopic can be a fundamentalist and integralist behaviour in implementing Kanban or SCRUM. Sometimes it can be useful to mix the two and, at least when starting, adapt your approach to the reality you are facing, trying to convey it to a more organic and structured approach.

How the four disciplines, frameworks or whatever you want to call them, LEAN, KANBAN, SCRUM and XP, can be thought as a matryoshka: one inside each other like the concentric onion skin.

How the words simply, small, granular, manageable, decoupled, make sense to reduce the WIP and the waste.

And again, how much important is to face the change and the new that born everyday. Being conscious of yourself, the others, the challenges you came across and forcing yourself to leave, once again, that damned comfort zone we tend to create around us.

How frustrating is to accumulate a technical debt, and that it must be considered as a loan that the project gives to you and soon or later, you have to reimburse it with a high rate of interests.

How is possible that we are survived as project managers, scrum masters, team leaders, developers or testers, especially when considering the extreme complexity of the software. A stratification of libraries, which are summaries of decisions taken by other people, maybe written by other people yet, in different timings, with different cultures, having substantially different mindsets. But, it seems, we are still alive.

And finally, how much is important to be assertive, to learn to actively listen to the others, trying to avoid the judgement. Understanding that the others, in the end, are trying to teach you something different than you and your world.

Thanks to the guys who spend their time sharing their ideas and thoughts: @fabioarmani, @nusco, @jacoporomei, @andreaprovaglio, @ziobrando, @mgaewsj, @xpmatteo, @carloz, @sleli.