In development, very often, the work to be done is new or contains specificities that make estimation difficult. How many projects are derailed due to poor estimates, themselves due to a poor understanding or poor expression of the need. As we can see, there are multiple causes behind estimation errors .
The team classifies the post-its of a project
In the iterative world of agility , planning poker , which is carried out to estimate in effort points, has the merit of starting from the following postulate: since the estimate in days or hours is unreliable, let's take an approximate rating scale without unit and exponential.
Thus, in agility, the Fibonacci sequence is often used to estimate the complexity of a story (or user story, i.e. a functional increment of a project or product). This sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, etc.) allows you to be precise on low estimates and to be more approximate on large estimates. Thus, an estimate between 1 and 2 effort points represents a difference of one to two, while an estimate between 11 and 12 effort points has less impact, so we favor the value of the higher Fibonacci sequence (or the closest depending on the practices) for safety.
Starting a project using the agile method
The practice of planning poker (decision poker in French) nevertheless has the drawback of taking time to estimate each of the stories of a project. Indeed, during its development, for each story, the project team decides on its estimate by vote (each vote for a number of effort points), then debates to agree on the value.
This form of estimation works when you need to go into detail and possibly combine the estimation with a phase of understanding the specifications of the story (the famous backlog refinement).
When a project starts, we often try to build an overall vision of the project , and for its proper management, to already have an idea of its landing point in time (beyond the official announced schedule which is an objective but not necessarily a reality).
It is of course possible to use the framing file, if it exists, which is based on the number of days sold for a fixed-price project for example. But once again, this is ultimately a profitability objective – is this estimate realistic now on the specifications to be built in detail?
This is where eXtreme Quotation can help you project into the project.
eXtreme Quotation is a practice that comes from eXtreme Pragramming, and is a form of ciphering like planning poker.
This practice aims to give an estimate of a large number of stories of a project , or of a release depending on the size of the project, in a very short time (1 to 2 hours maximum). We are talking here about the estimation of about a hundred stories.
EBOOK
Ultimate Guide to Digital Project Management
Download the e-book
What is the difference between eXtreme Quotation and planning poker?
Where planning poker offers to discuss each story in detail by line database debating, eXtreme Quotation offers to scan the stories simultaneously more quickly (the whole team is involved) and compare them to each other.
In planning poker, stories are evaluated more precisely, the result is often clearer stories and wolves are very often noted and dealt with during the session. But a poker planning session requires more time, and at the beginning of the project to build an overall vision of the latter, would require an incredibly long time. I have already attended planning poker dealing with 5 stories in the space of an hour. That's the time it takes, but not at the beginning of the project!
What are the steps of an eXtreme Quotation workshop?
This is a workshop that is carried out exclusively in person , because the team will be handling… paper!
Step 1: Preparation
To conduct this workshop, the Product Owner must print each of the user stories in an easily manipulated format. The stories can also be written on post-its (a little longer, I grant you), what matters is the highlighting of the title and a brief description. So avoid references to page 689, chapter 2, paragraph 4 of the functional specifications.
Tools like IceScrum or Jira , which we use at Adimeo, allow you to export a complete backlog or a release in a printable format (PDF or via transformation on Excel).
The workshop takes place in a room with a large flat surface (table or wall) on which a non-numerical effort point scale will be placed . At Adimeo, we generally place 3 post-its to represent the scale: $, $$ and $$$ to indicate in which direction to place the stories with the least effort points and those with the most effort points.
Step 2: Discovery before the workshop by the team
Before the workshop (the day before, for example), the team is invited to read all the stories .
This reading session, I agree, is not very attractive, but can be energized with an introductory meeting to the project where its context is presented, as well as the project as a whole. This is important for the team to connect their reading to an overall vision. For the team's concentration, or at least to make this moment more enjoyable, think about breakfast and a few snacks during the day.
The goal for the team is to read the entirety of the stories (title + summary description). They can ask the Product Owner a few questions to request clarifications on the whole, but it is not a question of going into too much detail.
Allow 1 day to read a hundred stories, lots of coffee or fruit juice, and a few breaks.
At the end of this stage, the team will not have retained the entire backlog (fortunately), but in a combined manner, will have a good idea of the project and its content.
Step 3: Starting the workshop
After a vitamin shot, the agile coach or Scrum master opens the workshop and specifies the rules of the game . 5 minutes maximum.
Step 4: Team Estimation
The whole team at the same time, each person takes a story , reads it silently and comes to place it on the flat surface taking into account the estimation scale.
The stories are gradually positioned next to each other (possibly one above the other when the collaborator is sure that the estimate in effort points will be the same – but the ideal is to force yourself to position it before or after). When a collaborator positions a story, he takes the opportunity to check the stories to the left and right of the location, to ensure that the story is approximately between the two in terms of effort point. The placement is always done silently.
This estimate takes about 45 minutes for a hundred stories, until the stock runs out.
Clarifications of the stories can be requested from the Product Owner, but be careful not to turn the discussion into a workshop.
My advice
If the story is too vague and a debate is started, it is recommended to stop the exchange and put the story aside.
The project team proceeds to estimate the stories
Step 5: Challenge
Once all the stories are positioned, the team moves on to the "challenge" phase . The goal in this phase is to review a few stories by comparing them with neighboring stories that are more or less distant. The idea here is to make sure that their position on the effort point scale is ok.
For example, we take a story at random on the table and another one located 2-3 positions to the right or left of it. A rereading of the story is done aloud and the team is questioned to check that they agree with the order of positioning of the two stories: Is the one on the left actually “simpler” and/or less “long” to complete than the one on the right?
During this phase, just like the previous one, one or more team members may raise technical questions about the feasibility of a story. Rather than answering the problem by transforming the discussion into a debate, it is possible to mark the story with a post-it or a symbol to indicate that a preliminary technical workshop will have to be carried out to design the technical response. It will then be possible to review the story's estimate at that time.
Best practices
During this phase, the Scrum Master can try to re-energize the session by participating in the challenge, mainly by randomly searching for stories and questioning the team with formulas like "are you really sure?" Whether he knows the answer or not, the goal here is to confront the team in these choices.
The Product Owner, for his part, can take a look at certain stories, the most expensive ones or those that seem high "for what they are" and indicate this to the team with formulas like "if it's that price, I'm going to review my copy, I find it high!". Be careful, the objective, here again, is to challenge the team in its choices - not to force it to lower its estimate (which would be counterproductive). The Scrum Master must ensure this.
