Category Archives: Software Engineering

How should we estimate software sizing in a software development project when using Agile?


In this post, I will focus on how should we do estimates in an Agile project.

Just to set the proper context, it is important to keep in mind the main tenets of Agile:

In any Agile project, the primary measure of progress is working software, which means that any other kind of deliverable is basically of low value.

Another main tenet is simplification: Maximize the amount of work not done!

During development, we need to be able to control the process, and we all know that we can’t control what we do not measure, so we do need some estimates.

But we should choose any software sizing estimation technique that is good enough for us to deliver working software: the focus should be on good enough!

When it comes to Agile estimation techniques, there’s a lot written about it.

On most books and articles on Agile Estimation techniques, the lion’s share goes to a technique popularly known as Planning Poker.

I agree with the idea that Planning Poker is fun to do, but I also agree with the well established fact that any team using Planning Poker will require a lot of time to complete this activity for a set of user stories. A lot of time spent on anything different from delivering working software is the wrong thing to do when you are using Agile.

Spending a lot of time on estimates is not consistent with the idea of maximizing the amount of work not done (more on this at the end of this post!).

There are alternative techniques, some of them are better versions of Planning Poker. Among the few techniques that have succeeded where Planning Poker has not is a technique known as Silent Grouping.

Even though Silent Grouping shares some elements with Planning Poker, it has avoided to include the elements that in PP contribute the most to the long duration of the sessions.

What is the basic “operation” of Silent Grouping?

The “game plan” for Silent Grouping has a Setup stage, two rounds of estimations and a Reflection stage.

The main elements are a card for each user story to estimate, a PP Board and a Parking Lot.

The most important aspect in the entire “game plan” of Silent Grouping is that the participants do not talk to each other during the two rounds of estimations (thus the “Silent” reference).

It is meant to eliminate, as much as it is possible, any kind of discussions among participants during the rounds.

At the Setup stage, the moderator will lay the ground rules of the session to the participants, and set expectations.

During the first round, the team members that participate in the session stand in a queue, so that each member has to wait for her/his turn. When it is the turn of a given team member, she/he will pick up the next card from the stack of cards to estimate, and put the card at the board within the “swim lane” that belongs to the number of points that the member considers to be the closest estimate for that given user story.

During the first round, each participant will give feedback on just one single card for each given turn at the board.

If the list of participants is small and the set of user stories is large, participants will have to iterate as many times as necessary so that each user story card is assigned an initial estimate.

Even though any given participant may give feedback on more than one card during the first round, any given card with have feedback from one and only one participant during the first round.

The board with “swim lanes” shows at the top the number of user story points for that group (thus the “Grouping” reference). Typically, the board will have 8 “swim lanes” or groups.

The first “swim lane” at the left side of the board has the number 1 at the top, and the number increases for each following “swim lane” to the right according to the sequence of Fibonacci numbers, typically until the number 34 (that 8th number in the Fibonacci sequence):

1, 2, 3, 5, 8, 13, 21, 34

(Did you ever wonder WHY is it that the Planning Poker Board NEVER has a number bigger than 34?)

During the first round, participants give feedback on card estimates in complete silence.

During the second round, the participants stand in a queue.

When it is the turn of a given team member, the participant is free to change the estimate of all the cards, by moving each card and placing it at the board within the “swim lane” that belongs to the number of points that the member considers
to be the closest estimate for that given user story.

It is possible that during the second round, some of the cards suffer a lot of moves. It is the responsibility of the moderator of the session to take note of these “controversial” cards (the cards that get shuffled at lot).

This second round is also done in complete silence: Participants give their feedback just by moving cards, one participant at a time.

During the second round, each and every participant is free to give feedback on the estimates of each and every card, but this time, each participant will have one and only one turn at the board.

Once the second round finishes, the moderator will place all the “controversial” cards in the Parking Lot (any kind of place holder for these “outlier” cards: a box, a basket, etc.).

At the reflection stage, if there are any “controversial” or “outlier” cards, participants will resolve any disputes of estimates for these cards only, but this part should we run without any kind of discussions or arguments. The goal is to either agree on a fast estimate for each card or else.

The Product Owners should not participate in the rounds of estimations, but could give feedback to participants during the reflection stage, if and only if any participant has questions regarding any given “outlier” user story: just short answers to simple questions.

Regarding this “outlier” cards, two possible outcomes could happen during the Reflection stage: the participants are able to easily resolve the dispute on the estimate of a given “outlier” card, or they don’t.

If they easily resolve the estimation dispute for a given “outlier” user story, everything’s fine with that user story.

If they are not able to resolve the estimation dispute for a certain user story, I can tell you that the estimate is not the ONLY hard question that the participants are not able to answer regarding that user story!.

In a sense, Agile is an adventure of exploration and discovery around a given set of user stories.

When the team members cannot agree on the estimation for a given user story, it could be a clear indicator that the team has not explored that user story enough at that point in time, so, the user story is not ripe enough for development.

If your team faces this kind of problem with any given “stubborn” user story at the end of the Reflection stage of a Silent Grouping session, the moderator should set aside each and every “stubborn” user story for further exploration and discovery.

As any Agile team is free to organize itself to solve any issue, the team should decide on how to deal with this situation: which of the team members should work on the exploration and discovery of the “missing” details of the “stubborn” user stories?

After the necessary stage of exploration and discovery is done for all user stories, they should be all ripe for rapid estimation and development.

On any given project, a team may need to run a few estimation sessions to cover all user stories, mainly because on any given project not necessarily all user stories are known from the get-go.

As a parting thought, we have come to the conclusion that any estimation session in Agile should always be a fast affair.

We should use techniques like Silent Grouping instead of Planning Poker, and most importantly, the team should never waste time feuding on estimates.

The proper way to deal with “stubborn” user stories is to set aside a group of team members to do some further exploration and discovery of the details of such user stories.

Kind regards, GEN

Agile and Estimates (I): the nature of projects that require the use of agile


Estimates are very important for any kind of project, including those projects  that require the use of agile, there is no question about that, but this brings to the foreground another set of important questions:

  • how do we use estimates in an agile project?
  • are there differences in the use of estimates with agile projects (when compared to the use of estimates in “traditional” projects)?

To be able to answer these questions, we need to explore some important characteristics of the nature of the projects that require the use of agile.

So, what’s the deal with the nature of certain types of projects that require the use of agile? Well, the kinds of projects that may need the use of agile have at least one of the following characteristics:

  • The company is exploring and developing an entirely new business model, so, business rules for this new business model are being explored and understood along with the project.
  • The company is developing a new type of product or service based on a new type of technology, so, there are no experts as this is a new field.
  • The company is using new software tools and technologies, or is adapting and customizing open source tools to its own needs, so the dev team has no experts on these tools and technologies.

If the company in question is a startup, the project will have all these characteristics, but even if the company is not as startup and/or the project has only one of these characteristics, it clearly will benefit from the use of agile.

So, the main factor in each one of these characteristics is uncertainty in a very high order of magnitude, very much in line with the kind of uncertainty you would expect in a typical Research and Development project.

In fact, agile projects and R&D projects share enough elements in common pertaining to the impact of uncertainty, that some of the project management tools and techniques that apply to R&D projects may also apply to agile projects.

One such tool that is useful for agile, just as it is useful for R&D projects, is the PERT estimation formula. Even though the historic background of the development of the project management tools collectively known as PERT is really interesting, it makes more sense to focus our attention on the estimation formula itself.

In agile projects as well as in R&D projects we may have a group of experienced professionals exploring how to solve a problem while “navigating through uncharted waters”. Under such circumstances, when trying to work out estimates, they will offer a range of values for any given task, from optimistic to pessimistic, and with some intermediate values being the most frequently proposed.

Taking this into consideration, the PERT estimation formula is based on a skewed distribution, the Beta Distribution, that properly takes into consideration the nature of such processes. Duration estimates are always positive, and it makes sense to use a balanced approach capable of compensating for overly optimistic or overly pessimistic values used in the estimation process.

The PERT estimation formula is very useful to provide “good enough” task duration estimates provided by experts under conditions of high uncertainty.

For this case, the estimation value is based on the median for this skewed distribution.

The PERT estimation formula expression is the following:

Te = (To + 4Tmp + Tp)/6

Where Te is the estimation for the duration of a given task, To is the most optimistic value for the duration of the given task, Tmp is the most probable value for the duration of the given task, and Tp is the most pessimistic value for the duration of the given task.

This estimation formula offers a balanced approach based on a weighted average, giving more importance (4 times more importance) to the most probable value, while still taking into account both optimistic and pessimistic values.

In an agile project, how do we get the values to apply to this formula?

It would be in meetings like the Planning Game, or in a Sprint Planning Meeting where the team can obtain estimates from the team members for each task, and out of the range of estimate values for each task it would be easy to determine the 3 input values for each given task needed for this estimation formula.

For each given task, the most optimistic and most pessimistic values are easy to determine, but the most probable value is not that obvious to determine. The most probable value is the mode, and the team must create a histogram for each task with the value of all the estimates for each given task. The mode corresponds to the class of the histogram that has the tallest bar. Sometimes, histograms for estimates look kind of weird, like with more than one hump (that’s a multimodal histogram): we will discuss about that in a follow-up post.

It is very easy to determine the mode for any list of values with a tool like Excel or Open Office.

This sheds some light on what approach to use for task duration estimation out of the range of values that the team proposes for each task during any planning meeting, but it does not offer many clues regarding the differences (if any) on how to handle estimates in an agile project. We will discuss this in a follow-up post.

Kind regards, GEN