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!

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

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

Scrum metrics: when to use?

Metrics are numbers, figures; they cannot represent reality….but they could be triggers that help in taking decisions.

Metrics, in software development, are usually requested by managers that want to know about the teams’ performance.

Agile teams usually know very well about their performance and the quality they are putting in. They also know quite well what’s the magic formula, that is different for every team, to balance  effectively perfomance and quality.

One day it happens, though, that pressure starts to grow.
The ProductOwner asks for some more functionalities, usually because of some changes about new ‘absurd’ deadlines. Obviously, the team tries to find different solutions or compromises engaging both the ProductOwner and the management people, but business is business they say.

The team struggles in balancing the requested increased level of performance, with the high quality standards agile prescribes, whatever XP, Scrum, Kanban or any other approach you are using. The healthy practices like pair programming, test driven development, refactoring, code inspection are slowly but progressively put apart.
This situation is disruptive for quality as well as for the team.

But, what I’ve noticed is that providing the right metrics to the management, could be the key factor that helps teams to face the situations like the one just mentioned.
Let’s see how.

First: your metrics obviously will report performance data like the velocity (user story points finished within each iteration).

Then, remember to associate to the velocity, also the metric ‘remaining story points’ (story points related to stories not finished within the sprint); that’s a metric that can mean at least two major things:

1. The team wronlgy selected too much stories (e.g. due to estimation errors)
2. The team was forced to select (consciously or unconsciously) too much stories (e.g. the CEO decide a new deadline and the PO pushes for more stories)

Usually, if the problem is how the team makes the estimations, this number will decrease progressively the next iterations, until it will reach zero.
When, on the other side, the PO and/or the managers push for releasing more stories, that number won’t decrease. This situation is also witnessed by other qualitative indicators.

Gather other qualitative information like the coverage of the unit tests, the # of test successfull/failed, # of issues closed vs new ones, # of broken builds, can help to study the qualitative trend of the product.

This data should be automatically collected by continuous building and integration systems and, again, automatically aggregated in database, in order to let the team remain completely focused on the development.

Once I have that data, I usually create two different graphs: the radar and the line graph.

The radar graph represents the results of each sprint, joining together different indexes. This kind of graph, actually, gives also a visual representation of the covered area: the larger, the better. The line graph helps to see what’s the underway trend of quality, verifying for example if some corrective actions done in the past, have brought any results.

Hence, let’s first concentrate on the radar graph. What I make is to transform the data just collected (see above), in qualitative indexes (e.g. from 1 to 5: 1 poor…5 excellent). Then, I calculate a Quality Index (QI), which is simply the sum of each index.

I’m not yet satisfied.

I do not want to assign the same weights to all indexes. Indexes like the # of tests sucessfull and  the coverage of the unit test or, furthermore, the # of broken build, must have different weights.

The successfulness of tests are something that I assume is somehow taken for granted. When a developer writes a unit test, I assume that she writes the code correctly.
Talking, instead, of indexes such as the broken builds or the coverage, I consider them much more important, because break a build or have a low unit test coverage, is something really bad.

This is the reason why I assign weights to the metrics I’m studying, like the ones below reported.

Now it’s time to recalculate the indexes according to the weights just assigned to each.

And finally, my graphs magically appear!

Here it is the radar graph where every axes represent an index.

The line trend graph is displying the QI, that is the sum of all the weighted indexes.

Remember, metrics are numbers.

Do not rely only on them when it’s time to take decisions: use this data to prove and certificate your feelings, impressions.

 Often your gut feeling is better than any metric!

Have fun

Why automate testing?

Are you really sure that only putting testers in the same room as others team members, let you deliver free-bugs & high-quality software?

In the previous post, I wrote about how to bring testers in the war room, with the other team members, identifying a possible agile testing process.

What I tried to describe was a raw hypothesis of what testers should do to cope with an agile enviroment: collaborating with developers and ProductOwner, writing test scenarios and test cases, writing automation tests and executing them, as well as performing exploratory and performance testing.

The scope of this post, actually, is to convince the ones of you not yet convinced, that it’s time to start automating tests, by telling a “nice” story.

Firstly, I would suggest the book “Agile Testing: a practical guide for testers and agile teams” written by Lisa Crispin and Janet Gregory. Several of the ideas and suggestions I gathered about agile testing, actually come from such a book.

Why Automate?

When developing a software, the time inexorably passes and, the application being developed, becomes bigger and bigger, and complexity increases; it will soon take too long to have it completely manually tested.

A condition like that, is primarily responsible of three common drawbacks:

1. team velocity decreases because developers start to help testers in their testing activities, instead of develop
2. or/and costs increases, because more testers are put into the team
3. or/and quality decreases because of the user stories start to be delivered not fully tested, due to few time and too much things to do

A real nightmare, isn’t it?!

What usually happens in a scenario like that, actually, is that testers start to struggle because of the few time available. They inform of such a situation the whole team during the daily meeting.

The ScrumMaster, in order to promote team self-organization, suggests that developers could help testers in executing manually testing, to solve that temporary problem. This choice drives the whole team to deliver less stories, respect to what initially committed, and a sensible decrease of the velocity starts to be detected.

The ProductOwner is daily informed about the situation, he starts to be worried.

During the next retrospective the team reflects about the problem, concludes that is not a temporary situation, hence decides to ask for new testers.

New testers arrive and it happens that, according to the brooks’s law, it takes more time that estimated to have them completely productive because they have to learn and practice and often pairing with others testers. At the next demo the team presents again even less stories respect to what was decided. The ProductOwner continues to be worried.

The ProductOwner then starts to push the team in having more stories released, asking and obtaining to avoid some quality checks and having less testing.

Software quality starts to decrease and this trend is showed by looking at the quality data gathered at the end of each sprint: Unit Test Coverage, Test passed/failed, broken builds, software quality metrics.

The technical debt increases, daily, and the ProductOwner decides to bring the problem to the management, asking for a refactoring sprint, that actually further delays the final delivery.

What about start automating tests?

There are many tools available and most of them are open  source tools, which cover all of the following categories:

• Testing WebServices
• Testing Web Application
• UAT and Integration Testing
• Data Generation Tools
• Database testing tools
• Performance Testing Tools
• Database Usage
• Application Bottlenecks and Memory Leaks
• Security Tools

Defining an agile testing strategy

When coaching teams coming from waterfall or any phase-gate software development model, one of the biggest issues is to bring the testers lwithin the teams. Nor the testers neither the developers are accustomed to work together.

What any agilist knows, is that every user story must satisfy the acronim INVEST:

• I ndipendent
• N egotiable
• V aluable
• E stimable
• S mall
• T estable

Actually, who is in charge for the first five letters is the ProductOwner. Being able to negotiate and then produce an indipendent, small and valuable user stories is, in most of the cases that I’ve encountered, not an easy job to do.

What, indeed, is easier for the team having that type of story, is to estimate it.

But then arrives the capital T, the last phase of a user story, before it is released: the testing phase.

As you probably know within an  iteration you will have several user stories, depending on the lenght of the iteration itself. Some of them are developed just few days after the planning meeting, some other are finished just few hours before the demo.

How is possible that every user story, before it is released even internally, should be tested?

I would make three separated considerations:

1. You won’t be able to deliver all the user stories completely tested, if you do not bring testers within the team, giving to them an agile testing strategy to follow.
2. You won’t be able to deliver all the user stories completely tested, if you do not automate yuor tests.
3. Even if sticking with the two points above, it can happens that some user stories are not definetly tested. What to do?

The first problem, I think, is the most tricky because it has to do with people, behaviors, working habits, leaving the comfort zone: in few words, a real mess.

But we, as agile coaches, never give up and so let’s see how to define a first draft testing strategy to rely on, letting developers and testers work together, even with a first raw process. For sure, they will somehow amend it during the first retrospective, trying to improve it; but actually it is wath we want: do you remember the words ‘inspect’ and ‘adapt’?

Viewing the problem by the tester side, a possible agile testing approach for each story, could be:

1. Write high level testing scenario
2. Write detailed testing test cases for the scenario
3. Automation tests creation
4. Automation & Manual test execution
5. Final validation

But, take a closer look to such a process.

The picture above, depicts the five macro steps in terms of macro-activities that a tester should do in order to complete the testing phase of a user story. As you probably noticed, for some activities, within brackets are reported the PO (ProductOwner) and DEV (developer) labels, that means those items must be collaboratively executed with them.

In general, an agile tester has a lot (and amazing) of things to do: participate, as any other team members, to the planning meeting, engaging the PO in order to have more details if needed, user stories’ acceptance criteria, any UI mock up, examples on business rules behaviors, and so on.

Probably, the day after the planning meeting, she starts to reason about the first user stories with the developer and the ProductOwner and she starts to write the first high level scenarios, that should be, even not formally, validated by the PO.

It’s time to collaborate (pairing) with the developer understanding how he wants to realize the requirement, giving to him any insight, suggestion or advice and gathering all the information the tester needs to start testing. Once she has a clear idea of what the user story must do, she starts to write the detailed test cases.

Now, it’s time to spend time in creating some automated tests.

Automation in testing is not the scope of this first post, a second one will arrive soon.

For the moment what we should know is that, as Mike Cohn said in his books and posts, test automation in general can be thought as a pyramid with different layers: the unit test level (developers are in charge for it), API level (both develpers and testers can be responsible for it) and finally UI level (mainly in the hands of the testers).

Every level depends on the robustness and reliabilty of the previous one: API tests depend on Unit Tests, UI tests depends on API tests.

Regarding unit testing and UI testing much has been said and written, let me explain what the API tests are actually.

These tests are also called ‘behind the GUI’ tests’. They are tests able to avoid the GUI interaction, directly addressing the API methods, subroutines or functions that are called by the GUI itselfs. Usually these routines are contained in libraries, DLLs, web services, that are instantiated by th GUI via a remote call, SOAP, REST, whatever.

Automating this level is quite simple and has, in my opinion, an high ROI in terms of effort to be spent and returning software quality.

By the way, coming back to the strategy, once the tester finishes to write the automation tests, she executes and adds them to the continuous building process, in order to avoid any regression.

Then she is ready for the final manual  and performance testing, before executing the User Acceptance Tests with the PO.
This last step, finally, ends the process.

Some few additional words about the collaboration between the developers, testers and PO. This should happen during the entire user story lifecycle.

A SCRUM lesson delivered using….SCRUM

Last week I had the pleasure to teach Agile and SCRUM. The class was quite challenging because the attendees were all PMP certified, with a deep experience in managing ITC projects. The class was also quite heterogeneous because of the different types of projects they manage and because of the different expertises.

In a class like that, teaching agile could be tricky because the experience and the approach of the attendees is such that topics like Planning, estimating, risk management are paramount and you will be challenged for sure when explaining how agile embodies those topics.

This is the reason why in courses like that one, I make huge use of games, exercises and confrontation sessions (a little bit of coaching never hurts) in order to facilitate the learning process of the participants letting them to consolidate the knowledge just aquired.

Knowledge is only a rumor until it’s in the muscle (Papua New Guinea proverb)

One another trick I use when teaching SCRUM is to arrange the lesson using SCRUM itself.

First of all, I arrange a fantastic taskboard with three columns: Backlog, Running, Done.

The backlog column contains the topics I’m going to cover, as post-its. In every post-it I write the name of the topic and on the left or right corner I write also an estimation in story points.
This estimation is a blend of these factors: number of slides covering the topic, importance of the topic, difficulty of the topic and finally how much space I should left, to let the attendees to reason, talk, discuss, confront about that.

Then arrives the calculation of the total story points I muyst deliver in that session, summarizing the points of each topic.

Good, now it’s time to draw the burndown chart.

I decided that the duration of my hypotethical day is one hour.
The burndown chart is a standard one: on the Y axis I report the total story points just calculated; the X axis, however, is divided into the N days available (the number of hours available for that teaching session).

The preparation is finished, now it’s time to work, explaining the contents of the lesson.
Every time I start a new topic, the relative post-it is moved from the Backlog column to the Running column. On the other way round every time a topic is completed it goes from the Running to the Done column.

Every hour I check the status of the work delivered (topics covered), how much work is again in the backlog, the time remaining and I say to myself and to the class what we are going to do in next hour and if we are on track or not. Think of this as what a team does every morning conducting the SCRUM Daily Meeting.
Then, the burndown chart is updated with the story points left.

I found this approach very usefull.
Visualizing what topics are still in the backlog, helps you to remain focused and to decide to slow down or accelerate.
Visualizing the burndown chart reinforces what just said in the point above.

The class sees how many topic must still be covered (taskboard), it sees what this does mean in relation with the time available (burndown chart).
This actually, allow the class to automatically regulate the way the attendees ask for questions, the need of any break, the way how they discuss: they obviously want to cover all the topics, maximizing the value and reducing any waste of time.

I think, however, that the most important point here is to let the class see how SCRUM works.

This helps the attendees in the process of digesting the SCRUM knowledge, transforming it from a only rumor in their brain into an abilities they can train and use soon.

What I hear, I forget.
What I see, I remember.
What I do, I understand.
(Confucio)

The magic wand coaching technique

That’s enough for this post.
I’m going to talk shortly about the other coaching techniques in some future posts.
Have fun!