Agile Raw Affinity Estimation

Let’s say You have just finished to create the user stories for your product and, a bit proudly, your product backlog now counts two or three hundred of items. How can you estimate them, effectively?

It is not always possibile to have all the items of the backlog estimated using the planning poker game. This estimation is somehow precise, but it is actually time consuming and not practicable in one-shot against the whole backlog.

Having a quick first rough estimation of the whole backlog, however, could be the right answer in order to start planning for the development of the product, dividing the effort in releases and giving some forecasts to the management, in terms of schedule and budget.

Actually, we are assuming that these first estimations won’t be perfect but, at last, what estimate is perfect? And moreover during the initial phase?

A technique that could help here, is the Agile Raw Affininity Estimation. I usually organize a workshop of 3/4 hours, within which the team usually can estimate more than two hundred stories.

Participants, material & preconditions

The participants involved are: the ProductOwner, the ScrumMaster and the core team. One important constraint is a logistic one: the room where you are going to hold the meeting, must have wide walls where to stick the user stories.

This is the material you will need:

• A4/Letter sheets
• Markers
• Post-it notes
• Paper tape

And these are some pre-conditions:

• well-formed stories (U-INVEST),
• the ProductOwner should have already presented the stories to the team even if at high-level (epics)
• the stories must be all printed each on a A4/Letter sheet (take care of the font size you use: every story must be clearly readable from 2/3 meters away from the wall) ,
• a printed copy of the team’s definition of done.

These are the main steps of the technique:

• Workshop explanation
• Silent estimation
• Story points estimation
• Estimation review
• Consolidation

Workshop explanation (Coach/ScrumMaster)

The Coach/ScrumMaster explains the team and the ProductOwner, the scope of the meeting and come into a detailed explanation of the process’s steps.

It’s important that s/he stresses the rules underlying the agile estimation (story points, complexity, relative weight, delphi, etc.) and remembers the team that each story estimation should aim to satisfy the definition of done the team already decided.

The Coach, then, sticks on the very bottom-left side of the wall, a sheet of paper reporting the word “SMALL” on it and on the opposite bottom-right of the wall another sheet with the word “BIG”. Finally, he rolls the tape from left to right, joining the two words.

This because, the team will hang the stories on the wall according to their size, forgetting, for this first step, about the estimation in figures, but reasonging about a gut estimation and positioning them in respect of the scale (SMALL>BIG) and of the other stories already attached (relative estimation).

The ProductOwner, then, gives the team the pile of user stories already prioritized (top of the pile most important stories).

Silent estimation (Team)

Now it’s time for the team to step in. During this phase the team remains silent. Every member has two possibilities: estimate a new story or change the estimation someone already did of a story.

Estimate a new story

In turn every team member, take a story from the pile, a piece of paper tape and stick the story to the wall, according to his/her perception of the story’s complexity (SMALL vs BIG) and in respect of the other user stories already hanging.

Change an existing estimation

The team member do not take any new story from the pile.

S/he detaches the story to re-estimate and sticks it again in a new position, according to her/his complexity perception and the other stories already hanging.

The process above described, continues until all the stories have been estimated.

Every team member can ask clarification about the user stories to the ProductOwner.

Story points estimation (Team)

Now it’s time to transform a position on the wall, in the corresponding estimation in story points. My suggestion here is to use the Fibonacci series.

The team writes each number of the series on a single post-it (1,2,3,5,8,13,etc) and attaches them near the line of the scale.

 Estimation review (ProductOwner)

Well, the team now deserves a break and a coffee and leaves the room.

The ProductOwner, which remained silent during the whole estimation process, could necessitate some clarifications.

Thus, she takes small orange/red post-its and attach them on each story that needs a clarification about the estimation done.

When the team comes back, it gives the clarifications the ProductOwner needs about the estimations. Sometimes it happens that after the discussion, the team has new elements and decides to change the estimation, moving the stories down the scale.

Consolidation (Team + ProductOwner)

This is the last step of the workshop.

The team and the ProductOwner write on each user story, the right estimation according to the position and the corresponding number.

The ProductOwner, finally,  gathers the stories and inserts the figures into hte product backlog and that’s it!

A crowded agile event (PMI-Rome)

It was a good day in Rome the 12th.

Many people really interested in agile and most of them known a little about it. Thanks to the PMI-Rome for the well organized event.

See here a short report of the event: “Grande successo per la giornata su Agile Project Management“.

And here below the presentation I held.

Who is still saying we agilists do not plan at all?!

One of the worst myths of agile, is that people think agile means to not plan at all. Actually, we do not plan in a traditional way, beacuse we use the rolling wave planning technique and we make a great use of visual management.

When starting a new agile project, there are some mandatory plan steps that, in my opinion, every organization should take. Before the first line of code is written, management needs estimations, even raw, dates, plans; this to understand how to finance the project.

Usually, we have a bunch of events we should keep into account.

First of all, a first high-level requirement gathering must be done in order to have clear understanding on what main features the product should have, according to the business value to reach.

This is the responsibility of the ProductOwner, who is the client or a representative of it.

Then, the product roadmap must be arranged: start and end date of the project, release dates, any important deliveries, final UAT, main milestones in terms of operations, marketing, etc.

Yet, now it’s time to arrange the user story mapping workshop (see here), to start creating the first version of the product backlog.

Ok, ok, I know. You already did a lot of work and you want to start asap with the first sprint. But, please, listen to me, calm down.

There are some last steps to perform.

To start the next sprint, you need to be sure that the most important user stories, the ones the team will work on immediately, are correctly decomposed and fine-grained. So, you should arrange a meeting with the ProductOwner and the team (Backlog Grooming), to be sure the stories are sized properly according to the sprint lenght and the team velocity.

Ok. Now it’s important to estimate the complexity in user story points, of each story and, indirectly,of the whole backlog. This will help you to make the release and iteration planning.

Use the planning poker game it’s not feasible when estimating too many user stories: it’s too much time consuming. One of the technique I use is the raw affinity estimation, which I’m going to describe shortly in one of my next posts. This technique let you to assign a first rough estimation to all the product backlog stories.

Now, you should have enough data to plan the product deadlines in terms of product release.

You [should] have:

• the total complexity of the product backlog,
• the velocity of your team/s,
• the main milestones

This leds you to the release planning (see here) where you put the epics (main features) on the timeline according to data above.

Finally, you are ready to sprint!

A lean approach to portfolio definition

When adopting agile as a product development methodology, the organizations wouldn’t forget to manage their portfolios accordingly.

It happens frequently that when organizations want to adopt agile, they think it’s only a matter of introducing just one more new methodology in the “assembly line”. They wrongly imagine that it’s only a matter of having the teams doing new things or, either, performing the old ones, better and more efficiently.

What they usually lose, is that introducing agile means to be ready to change organizational habits, behaviours, rules, policies, processes, tools, etc.

The portfolio management is one of the practices that should change.

Ok, let’s imagine you must arrange a portfolio of three different but inter-connected products, which will be developed using agile methodologies. You should have a first raw list of the main features each product should have (EPICS).

Then, You should arrange a workshop in which the most important stakeholders should attend: product managers, program & project managers, CEO, etc.

Be sure you will have post-its of different dimensions and paper tapes available and a large wall where to stick them: you will make great use of some visual management techniques.

Start the meeting, deciding the time-frame within which the products should be deployed.

Then, write the name of the products involved on the Y axis.

Now it’s time to ask the first product manager (or ProductOwner in SCRUM) to write each feature of the product on one post-it and hang it to the wall, positioning it on the timeline where it is supposed the feature must be available. This first chronological prioritization, must be done according to the business value each feature is supposed to bring to the organization.

Then it’s the turn of the second product manager.

Finally, the third product manager does the same.

Now it’s time to analyze and verify the interconnections between the products, asking the three product managers and the other stakeholders, to recognize and highlight any dependencies. This is one of the most important moment: the dependencies, indeed, can be conditioned by several factors: technical, tactical, financial or business ones; thus, choosing the right attendees for this meeting is paramount. It happens that during this phase new features arise.

According to the dependencies just drawn, the attendees must reason on how to reconcile every concern and necessity, by moving the features anticipating or delaying their availability.

Once the reconciliation above is finished, it’s time to analyze risks and impediments. This is a brainstorming session: each person writes on a post-it a risk or an impediment and stick it apart from the portfolio chart just defined.

The facilitator, arranges the items by category, clustering them, remove the duplicates and when the list is consolidated, asks the attendees to sort them by importance. Then, s/he assignes an identification number to each.

The facilitator, then, asks the audience about the impact of each impediment against the portfolio in terms of features, dependencies  or even months and/or products.

The workshop is almost finished. Now it’s time to collect the features and the related attributes (sequence, dependencies, dates, impediment references), into the product backlogs and the impediments list.

More reading here (see the book list page):

• Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum Craig Larman – Bas Vodde
• Scaling Software Agility: best practices for large enterprises, Dean Leffingwell
• Lean-Agile Software Development: Achieving Enterpise Agility Alan Shalloway, James R. Trott, Guy Beaver Net Objective Lean Agile series

Be good

Speaking at PMI-Rome “Agile Project Management in Action!” seminar

Friday the 12th of April, I’m giving a talk at “Agile Project Management in Action!” seminar, organized by PMI-Rome.

Besides me also participate great speakers from inspearit Italy, HP, TenStep and Ericsson; the seminar will be hosted by: Università degli Studi Roma Tre,  Facoltà di Economia “Federico Caffè”,  Via Silvio D’amico, 77 Roma.

This is the link to the registration page and this is the link to the detailed programme.

See you there!

User Story Mapping

Let’s say you are ready to start sprinting using SCRUM: have you already created a first raw version of the product backlog? Well, why not using the story mapping technique?!

When a ProductOwner find herself, for the first time, involved in the product backlog creation, it’s usually a real drama. This because she has to take into account many things contemporarily: the high level product’s vision, what the product should actually do as macro-functions, what are the relative micro-functionalities, identify any dependecies among them, etc.

The ProductOwner (PO) should work on these activities with the whole team, in order to get it completely involved and to let the team start visualizing the product, its functionalities and think pragmatically about it.

An interesting technique I usually use when coaching teams, is the user story mapping workshop, which  can last 4 to 8 hours, depending on the product complexity.

The first thing I like to propose, is to ask the PO to give a brief description of the product and its main functionalities and characteristics.

Then, the ProductOwner, writes down on post-its, the main activities a user can do with the product and hang them on the wall following the horizontal line of the timeline, sequencing them chronologically and the by priority.

For example, if the product were an email client, we could have as main activities: manage emails, manage calendar, manage contacts, etc.

Now it’s time for the PO and the rest of the team to identify for each activity, the relative tasks. In our example, the tasks identified for the Manage Email activity could be: Compose email, Read email, Delete email, etc.

Great, well done! We can proceed, now, defining the actual user stories that, as you know, must satisfy the INVEST acronym:

Indipendent (preferably not coupled with other stories)

Negotiable (the way it will be implemented can be negotiated)

Valueable (the story must be valuable for the ProductOwner)

Estimable (the story must be estimable by the team)

Sized-properly (the story must be small enough to fit, with other stories, into a sprint/iteration)

Testable (the story must be testable)

Coming back to the previous example, the task Compose email, could be decomposed in the following stories: Create basic email, Send RTF email, Send HTML email, Set email property, etc. Keep into account that, as Mike Cohn teaches us, a story should have the format “As a (role) I want (something) so that (benefit)”, the stories above reported for the sake of brevity, are not represented that way

This is the final step of the user stories creation, now the ProductOwner can gather the stories and write them down into the Product backlog. Most of the time, this first workshop won’t produce fine-grained stories, but it’s a mandatory step that will be followed by a new workshop usually called ‘Backlog Grooming’, where the team and the PO, work togheter on each story, in order to decompose it and analyze any dependencies.

Finally, before you can start with the first sprint, you will have to estimate the entire product backlog. It happens usually that the stories contained into the backlog, are hundreds; estimating all them using the planning poker game, is not feasible because it’s too time consuming. Actually, there’s another effective technique I’m going to talk about the next time, which explains how to estimate hundreds of stories in few hours, but please be patient for that.

And this is the result of one of the workshop I facilitated

Agile seminar at LUISS Business School in Rome

Thursday, the 28th of February I was one of the five speakers of am agile seminar organized by the LUISS Business School of Rome.

It was really a pleasure to participate: the organization was practically perfect and participation was high, I gave a speech about the agile teams and how they behave when running Scrum.

This is the link to my slides on slideshare.

IPMA YC Agile/Lean Portfolio Workshop

Yesterday, I had the opportunity to facilitate a workshop about Scrum and lean portfolio management. With Luca Cavone of JMAC, I coordinated a set of Scrum teams (the participants) in delivering three similar products using the Visible Planning (R) approach.

The workshop was organized by the IPMA Young Crew community, hosted by the MIP-Milan Politecnico University.

The first part of the workshop, was spent to create a common background among the participants, about the agile and the visible planning approaches: we delivered some sessions about agile project management, lean portfolio management and the Scrum framework.

Then, in the afternoon, we arranged the portfolio board.

And, finally, we gave to the teams: paper, scissors, tape, colored markers, post-it, magazines and an exercise: create a product box for an amazing new social network for marathoners and their coaches.

This product box (see here and here for an explanation) would have been created following the rules of Scrum (daily meeting, demo, retrospective, product backlog, etc.) and every end-iteration the ProductOwners with the PMO manager would have updated the portfolio board, in order to see any unaspected variations to what was planned during the planning/release meeting.

The simulation was really amazing and all the teams were really involved in putting their effort in finishing the products.

In order to simulate a real scenario, Luca and I,  introduced some noise into the pipeline, moving some team members from one team (the one that was ahead of plan) to another, simulating a sick team member pulling him out of the team for some days, modifying the priority of some user stories or, yet, asking for changes.

The feedback the participants gave was really good.

Are you ready to participate?

Have fun!

IPMA Portfolio Visible Planning® for an Agile Implementation

Saturday November the 10th, I’m helding with Luca Cavone, an agile workshop about about lean portfolio management for an agile implementation.

Click here for additional information.