nav-try-button

large_Team-running-refinement-meeting.jpg

medium_Team-running-refinement-meeting.jpg

small_Team-running-refinement-meeting.jpg

thumbnail_Team-running-refinement-meeting.jpg

Team-running-refinement-meeting.jpg

Learn how to run asynchronous planning poker with your remote team using SmartGuess. Our step-by-step guide simplifies the process and boosts productivity for effective agile planning. Try it today!

EstimatedBy field can now viewed in the Jira Backlog when configured correctly

large_EstmatedBy-Now-Avalable-In-Jira-Backlog.png

medium_EstmatedBy-Now-Avalable-In-Jira-Backlog.png

small_EstmatedBy-Now-Avalable-In-Jira-Backlog.png

thumbnail_EstmatedBy-Now-Avalable-In-Jira-Backlog.png

EstmatedBy-Now-Avalable-In-Jira-Backlog.png

The team must provide estimates beforehand, or everyone's time reviewing the stories and estimating before the meeting is wasted. In Smart Guess, this information is readily available in the Jira Backlog by adding the "Estimated By" custom field to the Card Layout. Check out the following post on how this is set up: [See who has given an estimate immediately when looking at your backlog](https://smartguess.is/blog/see-who-has-given-an-estimate-when-using-asynchronous-planning-poker/).

2. **Review each story together** - When all estimates are in place, one click to share estimates - will bring up the following screen  






large_StoryPoint-Estimate-Discuss-Decide.png

medium_StoryPoint-Estimate-Discuss-Decide.png

small_StoryPoint-Estimate-Discuss-Decide.png

thumbnail_StoryPoint-Estimate-Discuss-Decide.png

StoryPoint-Estimate-Discuss-Decide.png

* Share estimates with the team
* Discuss the differences
* Refine the story, define what you will do / not do
* Re-Estimate if needed
* Decide on the estimate

3. **Repeat until all stores have been refined**


## "The most efficient App for Asynchronous estimates"
Frederik Schottey, Founder & CEO at www.oakfields.io, [said in a review that Smart Guess was](https://marketplace.atlassian.com/apps/1225496/smart-guess-for-planning-poker-for-jira-cloud?hosting=cloud&tab=reviews):

> "The most efficient app we could find for doing asynchronous estimations. While other apps send you off to specific 'estimation' pages, Smart Guess allows you to do the entire estimation process right from the issue. Making the entire estimation process lightweight & intuitive, not yet another task team members have to complete." 


How to run the most efficient Asynchronous Planning Poker?

Björn Brynjar Jónsson

large_Bjorn-Brynjar-Jonsson.jpg

medium_Bjorn-Brynjar-Jonsson.jpg

small_Bjorn-Brynjar-Jonsson.jpg

thumbnail_Bjorn-Brynjar-Jonsson.jpg

Bjorn-Brynjar-Jonsson.jpg

"Want to see who has given an estimate when running asynchronous planning poker? SmartGuess has you covered. Our customers have transparency and accountability in agile estimation, helping them work efficiently and effectively. See how it's done!"

How the information is currently displayed will be improved by Atlassian. As the image shows, now full names are written out as a comma-separated list, which takes up a lot of space. Once Atlassian has improved on this, the field will be displayed like it is now being displayed within the Jira Issue view: 

EstimateBy field can be found in the Jira Issue View

large_EstimatedBy-In-Jira-Issue-View.png

medium_EstimatedBy-In-Jira-Issue-View.png

small_EstimatedBy-In-Jira-Issue-View.png

thumbnail_EstimatedBy-In-Jira-Issue-View.png

EstimatedBy-In-Jira-Issue-View.png

#### How it's set up for Company Manged projects
In three steps:
1. Open Board settings
2. Open Card layout
3. Add the 'Estimated by' field to the Backlog - view

Like so:

EstimateBy field can be added using the Jira Board settings

large_EstimatedBy-Added-to-BacklogCard.png

medium_EstimatedBy-Added-to-BacklogCard.png

small_EstimatedBy-Added-to-BacklogCard.png

thumbnail_EstimatedBy-Added-to-BacklogCard.png

EstimatedBy-Added-to-BacklogCard.png

### Problem: 'Estimated by' is not yet available at a glance in Team managed projects
For Team managed projects, this is not yet possible. However, this is an improvement planned by Atlassian. 

### Solution: Use Issue Search to access the status of estimates given quickly:
In the meantime, here is how you set up a JQL query to access this information efficiently.
1. New issue field "Estimated by" automatically lists what users have provided an estimate in Smart Guess
2. Create a simple issues search for your backlog using JQL
-  "project = TEST order by rank"
-  Replace the project key with your project 
3. Add the column "Estimated by" to screen
4. Save your search for quick reference

Keeping this issue filter close by, with one click, you see the status of estimates given at a glance:

large_Easily-See-Status-Of-Estimates-Given-With-Smart-Guess.png

medium_Easily-See-Status-Of-Estimates-Given-With-Smart-Guess.png

small_Easily-See-Status-Of-Estimates-Given-With-Smart-Guess.png

thumbnail_Easily-See-Status-Of-Estimates-Given-With-Smart-Guess.png

Easily-See-Status-Of-Estimates-Given-With-Smart-Guess.png

### Updating to the latest version
To update to the latest version:
1. Click "Apps -> Manage Apps" from the Jira top navigation
2. Find "Smart Guess" in the list and click  "Update." 

large_ManageApp-UpdateToLatest.png

medium_ManageApp-UpdateToLatest.png

small_ManageApp-UpdateToLatest.png

thumbnail_ManageApp-UpdateToLatest.png

ManageApp-UpdateToLatest.png

See who has given an estimate at a glance when using asynchronous planning poker

large_Surpriced-face-26170509_m.jpg

medium_Surpriced-face-26170509_m.jpg

small_Surpriced-face-26170509_m.jpg

thumbnail_Surpriced-face-26170509_m.jpg

Surpriced-face-26170509_m.jpg

Agile Planning with relative estimates is tricky. One-to-one mapping between story points and time doesn't exist. Learn how converting story points to time duration is measured based on past performance. As with any performance, your team's performance can decline and improve, and you have an impact. Learn what factors negatively impact your team's performance and how to convert story points to a time duration. 



## Coming back to the initial questions:
### 1. Why can't we negotiate and decide on the ratio between hours and story points?
The ratio is calculated based on a team's actual sprint velocity, i.e., completed stories from previous sprints. Hence every team will have a different velocity, and this is normal. Furthermore, the ratio is never fully fixed in stone. It will gradually improve or decline depending on various factors such as: 

**Factors negatively impacting team's velocity**
1. Team is attempting to deliver on an impossible deadline - cutting corners
2. Level of codebase technical debt is high 
3. Automated testing is in a bad shape
4. Team is lacking knowledge about parts of the codebase they're working with
5. Team is lacking knowledge about the technology stack they are working with
6. New team members will need support from existing team members to get quickly up-to-speed 

**Factors positively impacting team's velocity**
1. Team is working on a sustainable pace - constantly removing obstacles holding them back 
2. Technical debt is actively being reduced
3. Automated testing is improving - problems are found and fixed early
4. Team is gaining knowledge about parts of the codebase they are working with
5. Team is gaining knowledge about the technology stack they are working with 
6. New team members get good help when starting and get quickly up-to-speed 
 
### 2. Why isn't there a one-to-one mapping between story points and hours?
For the reasons mentioned above, there doesn't exist a mapping table mapping story points to hours. It depends on each team's context, experience, and current velocity.


### 3. How do we convert story points and velocity into duration?
Once information about a team's velocity and story estimates are in place for upcoming work, we can answer questions such as: 
1. When can you deliver feature A?
2. What can you deliver before the end of next quarter?
3. Can we get features A delivered before the end of next quarter?

Suppose the team's velocity is 30 story points every two-week sprint. Then in four weeks, they will complete approx. 60, in six weeks 90, and so on. If the team has five members and one member is away during a sprint, the velocity drops to approximately 4/5 * 30 = 24. 

Now we can answer questions for when and for how long the work we are planning will likely take: 

#### Question 1: When can you deliver feature A? 
This is a fixed scope, variable time question. During development, the team's velocity will always vary a bit. The green and red lines show variability in how many story points are competed in each sprint.

large_SmartGuess-When-can-you-deliver-feature-A.png

medium_SmartGuess-When-can-you-deliver-feature-A.png

small_SmartGuess-When-can-you-deliver-feature-A.png

thumbnail_SmartGuess-When-can-you-deliver-feature-A.png

SmartGuess-When-can-you-deliver-feature-A.png

So looking at the image, having a fixed scope question, when a certain number of story points are delivered, the answer is most likely in the following range:
- x gives the best-case scenario 
- y gives the worst-case scenario 

#### Question 2: What can you deliver before the end of next quarter?
This is a fixed time, variable scope question. Looking at the image, having a fixed time question, we can see that most likely, the team will
- Complete all stories below x
- Some of the stories between y and x
- None of the stories above z

large_SmartGuess-What-can-you-deliver-end-of-next-quarter.png

medium_SmartGuess-What-can-you-deliver-end-of-next-quarter.png

small_SmartGuess-What-can-you-deliver-end-of-next-quarter.png

thumbnail_SmartGuess-What-can-you-deliver-end-of-next-quarter.png

SmartGuess-What-can-you-deliver-end-of-next-quarter.png

### Question 3: Can we get feature A delivered before the end of next quarter?
This is a fixed time fixed scope question. Looking at the image, if x is not within the green and red lines, the team most likely will not be able to deliver feature A in time.

In this case, the discussion that needs to occur is how to proceed. There are only three real options:
- Give the team more time
- Cut scope
- Or a combination of both

large_SmartGuess-Can-you-deliver-feature-A-before-end-of-next-quarter.png

medium_SmartGuess-Can-you-deliver-feature-A-before-end-of-next-quarter.png

small_SmartGuess-Can-you-deliver-feature-A-before-end-of-next-quarter.png

thumbnail_SmartGuess-Can-you-deliver-feature-A-before-end-of-next-quarter.png

SmartGuess-Can-you-deliver-feature-A-before-end-of-next-quarter.png

## Watch Henrik Kniberg explain these concepts
Henrik Kniberg covers these concepts in his excellent video "Agile Product Ownership in a nutshell." The discussion on estimates starts at 11:28. 

large_HenrikKniberg-video-for-more-info.jpg

medium_HenrikKniberg-video-for-more-info.jpg

small_HenrikKniberg-video-for-more-info.jpg

thumbnail_HenrikKniberg-video-for-more-info.jpg

HenrikKniberg-video-for-more-info.jpg

**About Smart Guess** 

*We help teams educate stakeholders by providing actionable answers to common misconceptions about estimates. So more teams can use estimates to their advantage, and fewer are held accountable for delivering on impossible deadlines.* 

Like, retweet, or share your thoughts on Twitter about this topic.


Converting story points to hours - how does it work?

large_Studlagil-Iceland-127038898_m.jpg

medium_Studlagil-Iceland-127038898_m.jpg

small_Studlagil-Iceland-127038898_m.jpg

thumbnail_Studlagil-Iceland-127038898_m.jpg

Studlagil-Iceland-127038898_m.jpg

Discover why story points are a better alternative to estimating time in agile development. This post explains the benefits of using story points for more accurate planning and forecasting. Learn more about this popular estimation technique today!"


### Critical problems with time estimates
#### Problem: It depends on who does the work, how long it will take 
You will find experienced team members and less experienced members in any team. It will take less time for a team member to implement changes on a well-known codebase. Similarly, it will take more time to implement changes that depend on an unfamiliar API. Each team member has a different level of knowledge and experience. So when team members discuss time estimates, they struggle to agree on an estimate when each member is thinking 
> 'how long will it take 'me' to implement this story?'

We need a way to move away from this line of thinking because team members' knowledge and experience are different.

#### Problem: Uncertainty not actively tracked
When team members discuss a story and how they will get it done, they base their estimate on what they know. Some overlook what they can't see and give a best-case estimate. Some will assess uncertainty and include additional time to account for it. The big challenge is deciding how much time to account for the uncertainty. Because you only know how long it takes when the work is complete. So while uncertainty isn't being assessed, measured, and used to forecast progress, your team will struggle with estimates.

There is a solution to these problems. The answer is to use story points, relative estimates, and the team's velocity. Let's discuss how it works. 



### How do story points, relative estimates, and team's velocity solve these problems? 

#### Solving: It depends on who does the work, how long it will take 

Relative estimates solve the first problem. Instead of asking: 'how long will this story take me?' Compare each story you estimate and ask, is this story the same size as other stories that are:
- one-story point?
- two-story points?
- three-story points?

..and so on. Research shows we are better at estimating effort using relative estimates. And by using the Fibonacci sequence as the scale, rather than continuous scale such as time, the difference between each item makes it relatively easy to find a place for each story. Then end of each sprint, track the total number of story points the team completed. That's the team's velocity. The team's velocity will be approximately the same from one sprint to another, given team members are using a similar time each sprint and story uncertainity is similar to previous sprints. Each sprint has a fixed timeframe allowing teams to [convert story points to delivery time](https://smartguess.is/blog/story-points-to-time/) as needed. 

#### Solving: Uncertainty not actively tracked
We solve the second problem by *assessing*,  *measuring*, and *forecasting* progress based on actual data. We *assess* uncertainty when assigning story points. For example, when two stories are of a similar size, while one involves an API the team is unfamiliar with, it will get a higher story point estimate. Secondly, by *measuring* the team's velocity every sprint, we collect data on backlog items completed involving risk and uncertainty. By collecting data on the team's velocity, we measure story progress and the actual time uncertainty has taken. Third, we *forecast* progress using the average velocity of past sprints, allowing us to answer questions such as [covered here](https://smartguess.is/blog/story-points-to-time/):

1. When can you deliver feature A?
2. What can you deliver before the end of next quarter?
3. Can we get features A delivered before the end of next quarter?

The forecast will work while past velocity is a good indicator of future velocity.  Naturally, this will break down if part of the team frequently moves to other urgent work such as production issues, which is a topic for another post.

Story points: Why not use time?

large_cloudy_weather_121841500_90.webp

medium_cloudy_weather_121841500_90.webp

small_cloudy_weather_121841500_90.webp

thumbnail_cloudy_weather_121841500_90.webp

cloudy_weather_121841500_90.webp

Are you dealing with underestimation in agile development? In this post, Smart Guess shares valuable insights to help teams address this common issue. Today, learn how to identify and overcome underestimation in your agile planning process with our expert tips and techniques!


medium_Steve-Blank-No-Facts-Exist-Inside-The-Building.png.webp

small_Steve-Blank-No-Facts-Exist-Inside-The-Building.png.webp

thumbnail_Steve-Blank-No-Facts-Exist-Inside-The-Building.png.webp

Steve-Blank-No-Facts-Exist-Inside-The-Building.png.webp

Someone saying 'No, it's less effort than that!'? 

large_team-product-owner.jpg

medium_team-product-owner.jpg

small_team-product-owner.jpg

thumbnail_team-product-owner.jpg

team-product-owner.jpg

Are story points estimated by the product owner or the development team?
The short answer is the development team and there is a reason for that.

Another related question is should the Product Owner, Scrum master, or anyone else outside of the team provide an estimate? 
The short answer is no, they should not and there is a reason for that.

Are story points estimated by the product owner or the dev-team?

large_the-trap.jpg

medium_the-trap.jpg

small_the-trap.jpg

thumbnail_the-trap.jpg

the-trap.jpg

Are you tired of the heated and unproductive debate about Estimates vs. #NoEstimates? Today, it is clear polarization and division have overtaken the discussion. This is sad because #NoEstimates and Estimates work brilliantly when used correctly. So there is no reason for the heated arguments among Agile development enthusiasts. Smart Guess Agile expert and teacher review the scene, suggest moving beyond propaganda, and discuss avoiding the NoEstimates trap. 

You can find hundreds of similar tweets by searching for ['#NoEstimates estimator'](https://twitter.com/search?q=%23NoEstimates%20estimator&src=typed_query) on Twitter. 

## 3. Personal attacks rather than discussing the case
Another fallacy frequently used is attacking the person rather than discussing the case, i.e. [Ad hominem fallacy](https://en.wikipedia.org/wiki/Ad_hominem). 


## 4. Research shows repeating false statements make people believe
As covered in the posts a. [Debunking 'estimates never work'](https://smartguess.is/blog/debunking-estimates-never-work/) and b. [#NoEstimates straw man fallacy](https://smartguess.is/blog/no-estimates-straw-man-fallacy/). Few key #NoEstimates proponents are knowingly repeating false claims that 'estimates don't work.' In the following Wikipedia article on [Illusory truth effect](https://en.wikipedia.org/wiki/Illusory_truth_effect), it says that:
> researchers discovered that familiarity can overpower rationality and that repetitively hearing a certain fact is wrong can affect the hearer's beliefs.

There are hundreds (likely thousands) of tweets under the #NoEstimates hashtag on Twitter, claiming *"estimates never work"* or/and using the *"straw man fallacy"*. We see in these examples proponents are *"selectively presenting facts to encourage a particular synthesis or perception"*, [Wikipedia definition of Propaganda](https://en.wikipedia.org/wiki/Propaganda).


## In summary - is Propaganda used to advance #NoEstimates?
Based on the facts presented and methods used, the content manufactured to provoke and maintain the fire and the actions of the few proponents behind this. It is clear, quoting [Wikipedia's definition of Propaganda](https://en.wikipedia.org/wiki/Propaganda), we are seeing Propaganda used to:

> *" influence an audience and further an agenda"*

## Why is Propaganda used?
Why do we see Propaganda used to further the #NoEstimates agenda? 

### Selling books and services
It happens to be the case the few key proponents using these methods are selling books and services around the #NoEstimates theme - so this might have an impact. 

### Is the world a better place without estimates?
Another factor is the *belief the world might be a better place without estimates*. To make this claim, #NoEstimates proponents have created many posts, some of which contain the phrase ["#NoEstimates death march"](https://twitter.com/search?q=%23NoEstimates%20death%20march&src=typed_query&f=top).

I might need another post to explain the problem with this argument. In short, this is like saying we should ban knives, credit cards, etc. Because they can be used with negative consequences, let's keep in mind the tools themselves have no "agenda." It's always in the hands of the person using the tool to use it wisely. Therefore you can't claim tools such as knives, credit cards, or estimates are always bad. People making this claim are fighting the wrong battle.

Are we heading towards a future where we can't decide what tools or methods we use? 

large_Screenshot 2021-11-16 at 17.35.35.png

medium_Screenshot 2021-11-16 at 17.35.35.png

small_Screenshot 2021-11-16 at 17.35.35.png

thumbnail_Screenshot 2021-11-16 at 17.35.35.png

Screenshot 2021-11-16 at 17.35.35.png

## Moving beyond Propaganda
I think our future lies beyond the authoritarian world current propaganda is bringing us. While tools provide value, people will continue using them. Both estimates and no estimates provide value when used correctly. 

Shouldn't people have the freedom to decide what method or tools they use without ridicule, personal attacks, provocative false claims, and random confrontations?

## You shape the future
Each and everyone in the industry can make an impact. You have a choice, take the:
- **Blue pill** - If you want the #NoEstimates Propaganda to continue - do nothing. 
- **Red pill** - If you want the #NoEstimates Propaganda to stop - then read on
 
Share this post when you see the following behaviors: 
1. People repeating false claims, using polarizing content to grab attention 
2. People discriminating against others for using estimates
3. Personal attacks rather than discussing the case. 

As a last resort, stop following people showing behavior you don't want to see.

 It's that simple, until next time, cheers!

Like, retweet, or share your thoughts on Twitter about this topic.

**About Smart Guess** 
*We help teams educate stakeholders by providing actionable answers to common misconceptions about estimates. So more teams can use estimates to their advantage, and fewer are held accountable for delivering on impossible deadlines.*

Is propaganda used to further the #NoEstimates agenda?

Customer review from Frederick Founder &CEO @ Oakfields.io

large_Customer-Review-oakfields-homepage-hq.jpg

medium_Customer-Review-oakfields-homepage-hq.jpg

small_Customer-Review-oakfields-homepage-hq.jpg

thumbnail_Customer-Review-oakfields-homepage-hq.jpg

Customer-Review-oakfields-homepage-hq.jpg

The team at Oakfields.io identifies Smart Guess as "The most efficient app we could find for doing asynchronous estimations."

They just switched over from one of the most widely used apps on the market. Find out why teams are making the switch.

'The most efficient app for asynchronous estimations'

Screenshot from Smart Guess where user is configuring the estimate card deck

large_SmartGuess-Configure-Cards-2.png

medium_SmartGuess-Configure-Cards-2.png

small_SmartGuess-Configure-Cards-2.png

thumbnail_SmartGuess-Configure-Cards-2.png

SmartGuess-Configure-Cards-2.png

Inspired by a customer question last week, users can now configure story point values in Smart Guess. 

Further refinement scheduled later this week, will allow users to add their own card values, rather than being restricted to the default card values.

Smart Guess in action video - click to play

large_SmartGuess-Video-thumbnail-2.png

medium_SmartGuess-Video-thumbnail-2.png

small_SmartGuess-Video-thumbnail-2.png

thumbnail_SmartGuess-Video-thumbnail-2.png

SmartGuess-Video-thumbnail-2.png

The next release, scheduled later this week, will further enhance this functionality by allowing users to add their own card values.

Configuring story point values in Smart Guess - Part II

large_I-want-to-quickly-see-who-has-given-estimates.jpg

medium_I-want-to-quickly-see-who-has-given-estimates.jpg

small_I-want-to-quickly-see-who-has-given-estimates.jpg

thumbnail_I-want-to-quickly-see-who-has-given-estimates.jpg

I-want-to-quickly-see-who-has-given-estimates.jpg

In a discussion with a customer running asynchronous planning poker, they explained it was challenging to get a quick overview of the team's progress in giving estimates. 

Until today, users had to open each issue to see who has given an estimate and who had not. The 'Estimated by' custom field makes this so much easier.  

large_CustomField-ListingStory-EstimatedBy.jpg

medium_CustomField-ListingStory-EstimatedBy.jpg

small_CustomField-ListingStory-EstimatedBy.jpg

thumbnail_CustomField-ListingStory-EstimatedBy.jpg

CustomField-ListingStory-EstimatedBy.jpg

The new field, Estimated By, can be added directly to the Jira Backlog - Card layout - for Company managed projects, as can be [seen here](/blog/how-to-run-asynchronous-planning-poker/).  However, for Team managed projects, Atlassian has this on its roadmap, and we will let you know as soon as it's when it's available.

In the meantime, when you are using Team managed projects, this is how you can quickly see who has given an estimate in Smart Guess:

## Solution - quickly see the status of estimates given:
1. New issue field "Estimated by" automatically lists what users have provided an estimate in Smart Guess
2. Create a simple issues search for your backlog using JQL
-  "project = TEST order by rank"
-  Replace the project key with your project 
3. Add the column "Estimated by" to screen
4. Save your search for quick reference

Keeping this issue filter close by, with one click, you see the status of estimates given at a glance:



## Updating to the latest version
To update to the latest version:
1. Click "Apps -> Manage Apps" from the Jira top navigation
2. Find "Smart Guess" in the list and click  "Update" 
![ManageApp-UpdateToLatest.png](https://res.cloudinary.com/smartguess/image/upload/v1646735095/Manage_App_Update_To_Latest_e58d1ba2e7.png)


Asynchronous estimation with Smart Guess just got better

Hashing out different opions of NoEstimates 

large_noEstimates-debate.jpg

medium_noEstimates-debate.jpg

small_noEstimates-debate.jpg

thumbnail_noEstimates-debate.jpg

noEstimates-debate.jpg

Are you tired of the heated and unproductive debate about Estimates vs. #NoEstimates? Smart Guess Agile expert and founder explores the harmful effects of a black-and-white stance on the Estimates vs. No Estimates debate. The post offers valuable insights into how to find a middle ground that works for your team. Learn why moving the discussion in a better direction is essential. 


In this post, I will cover why taking this stance is harmful, cover what kind of interactions are feeding the fire, and ask what's the purpose of claiming Estimates are always bad.

## Why is the black-and-white stance considered harmful
Many who actively take part in the discussions, [Ron Jeffries](https://ronjeffries.com/articles/019-01ff/estimation-again/Index.html), [Your Daily Scrum podcast](https://youtu.be/YKYiFK-FJyQ?t=462), [Peter Kretzman](https://twitter.com/PeterKretzman/status/1450867463931908103?s=20) and others openly agree that keeping the discussions on these negative terms is not helpful. Let's cover why that is and what's the impact.

Let's start by looking up how leadership is defined. [On Wikipedia](https://en.wikipedia.org/wiki/Leadership) it says that leadership is:
> ..a practical skill encompassing the ability of an individual, group or organization to "lead," influence or guide other individuals, teams, or entire organizations. 

Being a leader means followers support your cause. Followers look to their leader for guidance and take on or repeat their behavior in some ways. That is why people in leadership positions need to acknowledge their role and live up to the responsibility that comes with it. 

For this reason, it is: 
- **critical leaders on both sides** of the discussion take care **how they act and what they say** 

Why, you might ask? 
- **Because leaders influence their followers and shape what kind of interactions take place!**

So when some of the key leaders of the #NoEstimates movement show the following behavior repeatedly, it fuels the fire:

1. [Claiming "estimates never work"](https://smartguess.is/blog/debunking-estimates-never-work/), i.e. [Faulty generalization](https://en.wikipedia.org/wiki/Faulty_generalization) fallacy
2. [Using examples of how not to estimate](https://smartguess.is/blog/no-estimates-straw-man-fallacy/) to support claims that "estimates don't work", i.e., making a [Straw man fallacy](https://en.wikipedia.org/wiki/Straw_man) 

### Why is this harmful?
It is harmful because when leaders show this kind of behavior, what happens is that followers take up the false claims, the aggressive tone, and the attitude their leaders display. This further damages the discussion and divides people. As seen all over online forums where followers make the same false claims, it seems to pick a fight.

Let's take a short example to explain the impact. A few months back, I read a post on Reddit about estimates, with lots of comments, and lively discussions. There were at least 4-5 comments (around 10-15%) from users picking a fight adding comments along the line, you know, 'estimates don't work,' essentially ridiculing the use of estimates. Given the response these comments got, it is clear many have grown tired of these arguments, and so much time is being wasted on unproductive discussions. 

So what kind of messages are feeding the fire? 

## What kind of messages are feeding the fire? 
When looking for answers to why so many in the software development community are making this claim, I came across tweets from Vasco Duarte, author of the #NoEstimates book. Vasco released the book in 2016 and is highly active on Twitter under the #NoEstimates hashtag. Nearly every day, Vasco posts multiple tweets under the #NoEstimates hashtag. His tweets are created to grab attention, dismissing the value of estimates and ridiculing people who use them. Seeing the following tweet, I wondered if he thought estimates never work. So I asked him the following question to understand where he stood on the topic:

I thought Vasco's answer below was quite positive because he is accepting it's valuable to have a tool '..allowing teams to make decisions about options that come up during backlog discussions'. In addition, he does not deny estimates provide answers.

To confirm this understanding, I followed up and asked:

What Vasco is saying is that estimates:
1. only work for people who use estimates for "..blaming, pressuring others, etc.." 
2. do not work "for containing costs or hitting a deadline"

Quickly browsing his tweets and looking for similar statements, Vasco is saying *estimates never work*.

**That is a bold statement.**

Why? Because logically making this claim takes only a single case, one example, where an estimate is used successfully to show statements making this claim are false. A post [Debunking the statement' estimates never work'](https://smartguess.is/blog/debunking-estimates-never-work/) shows these statements are false.

### What's next?
In the next post, I will dive deeper into the purpose of repeating these false claims, keeping the polarization in our community rampant. The following post, [Did you get caught in the #NoEstimates trap?](https://smartguess.is/blog/the-NoEstimates-trap/), shares an inconvenient truth about the methods we see used. 

**About Smart Guess** 
*We help teams educate stakeholders by providing actionable answers to common misconceptions about estimates. So more teams can use estimates to their advantage, and fewer are held accountable for delivering on impossible deadlines.*


Black and White stance on #NoEstimates considered harmful

large_tape-measure-2-small.jpeg

medium_tape-measure-2-small.jpeg

small_tape-measure-2-small.jpeg

thumbnail_tape-measure-2-small.jpeg

tape-measure-2-small.jpeg

Are you tired of the heated and unproductive debate about Estimates vs. #NoEstimates? In this post, Smart Guess debunks the myth that estimates never work and provides expert insights on why #NoEstimates proponents knowingly keep making false claims. Learn how to avoid this common pitfall.


I thought Vasco's answer below was quite positive because he is accepting it's valuable to have a tool '..allowing teams to make decisions about options that come up during backlog discussions'. Because he says with a "..simple slicing heuristic.." you can achieve this value. Thereby accepting the value of the premise. To confirm this, I followed up and asked:

## #NoEstimates author in contradiction - Value in Estimates or Not?
By looking at Vasco's tweeds above and the repeated tweets with the same message, Vasco is completely dismissing the value of estimates. Yet in his book, chapter 5, *'1-2-3: Step by step towards # NoEstimates'*, under the heading *' Move to story points'* he says that: 
> **Story Point-based estimation gives a better understanding of how things like risk, complexity, expected dependencies for each Story**, etc. Given that a large amount of time it takes to deliver one Story is spent waiting, **Story Point estimation is more likely to help you assess the true impact of one Story in your project.**"

So Vasco clearly understands there is value in estimates, yet consistently contradicts this every time he claims estimates:
1. are helpful only for "..blaming, pressuring others, etc.." 
2. do not work "for containing costs or hitting a deadline"

This doesn't make sense, or does it? Let's touch on this question before we close. But let's first debunk Vasco's false statement many have been led to believe that: 'estimates never work.' 

### Debunking 'estimates never work'
It seems Vasco and others who are repeating these claims don't realize they are logical fallacies. In the examples above, Vasco makes a [faulty generalization](https://en.wikipedia.org/wiki/Faulty_generalization). Here is the example from Wikipedia and the #NoEstimates fallacy side by side:

```
If one sees only white swans, one may suspect that all swans are white.
If one only sees estimates used with bad intentions, one may suspect all estimates are used with bad intentions. 
```

To debunk the statement' estimates never work,' we only need a single case, one example, where an estimate is used successfully to show statements making this claim are false. Let's extend the story from the #NoEstimates book, and let's introduce Carmen, the main character in the book, to the following case:

 **Case Example: Carmen and her team identify a better solution using estimates**
> Through discussion with users and stakeholders, Carmen identifies a problem the team needs to tackle. During a sprint planning discussion, it becomes clear there are different options available.

> During the initial discussions Carmen had, a solution idea was identified the stakeholders thought made sense to go ahead with. Later during planning, the development team's discussed the problem and the proposed solution, solution A. The team estimated the work might be around 13 story points. They expected it would take a bit more than one sprint to complete. The reason was that there were some known unknowns and unknown unknowns, as always. Given their information, history, and velocity, both Carmen and the team knew it would likely take between 1-2 sprints to complete.

> During the meeting, the team identified a different approach. Let's call it solution B. Estimating solution B, the team expects it to be around eight-story points yet provide the same value. Given their velocity, the story will likely be completed within one sprint. This is because there were no 'known unknowns' about solution B, so the team is more confident about this estimate. In other words, they expect the estimate for solution B will have less deviation than the estimate for solution A.

> Based on these findings, Carmen and the team agree to implement solution B. In addition, Carmen will validate their thinking and present a quick mockup of the proposed solution to actual users and stakeholders who took part in the initial discussion. To ensure they didn't miss anything during the team discussion and validate the solution delivers the value they are after.

By making this single case, based on real examples, we can see the claim that "estimates never work" is false. Cases such as these have come up again and again during my 20+ year carrier as a Software Developer, Scrum Master, and Product Owner. I am not the only one as teams worldwide are using estimates successfully in their work.

This raises the question, why on earth are some of the key #NoEstimates proponents knowingly repeating false claims that 'estimates never work'?

## #NoEstimates proponents knowingly making false claims
Now, this is an interesting question. In one part, it has to do with spreading the #NoEstimates idea, selling books, and related consultancy services. Another factor has a darker side, as many are trapped into believing the false claims and take up the harmful and aggressive [black and white stance on estimates](https://smartguess.is/blog/black-and-white-noestimates-stance-considered-harmful/) wasting a lot of time in unproductive arguments and causing polarization in our community.

## What's next?
In the next post, I will dive deeper into the purpose of repeating these false claims, keeping the polarization in our community rampant. The post, [Did you get caught in the #NoEstimates trap?](https://smartguess.is/blog/the-NoEstimates-trap/), shares an inconvenient truth about the methods we are seeing used. 

**About Smart Guess** 
*We help teams educate stakeholders by providing actionable answers to common misconceptions about estimates. So more teams can use estimates to their advantage, and fewer are held accountable for delivering on impossible deadlines.*

Debunking the statement 'estimates never work'

Smart Guess for Planning Poker screenshot

small_SmartGuess-Screenshot.webp

thumbnail_SmartGuess-Screenshot.webp

SmartGuess-Screenshot.webp

Received a question from a user on how to adjust story point values in Smart Guess yesterday afternoon. Short discussion, validating how to best solve the problem, inspired a small release that went live yesterday evening.  

In the next couple of days additional releases will make configuring story point values in Smart Guess fully configurable.

Configuring story point values in Smart Guess - Part I

large_new-straw-man.jpg

medium_new-straw-man.jpg

small_new-straw-man.jpg

thumbnail_new-straw-man.jpg

new-straw-man.jpg

Are you tired of the #NoEstimates vs. estimates debate in agile development? Smart Guess Founder and Agile expert explores how the straw man fallacy is frequently used in the #NoEstimates debate, as well as in the book, and shares valuable insights on why this might be the case. 


So instead of refuting *'best practices'* for estimating, key #NoEstimates proponents using this tactic are only up to refuting the *'worst practices'*. Why, might you ask? Because that's an argument that can easily be won. In the example, we see a fictional case of how not to think about estimates. However, the real subject of the argument - how you would use estimates - was not discussed at all. So what we see here is, quoting Wikipedia's definition again:

> having the impression of refuting an argument, whereas the real subject of the argument was not addressed or refuted, but instead replaced with a false one.

## Straw man fallacy backbone of #NoEstimates book
The same fallacy is the backbone of the #NoEstimates book. Even though the book was released in 2016, it is like the story happened in 1996. Why? Because none of the Agile best practices from 1996 - 2016 are part of the 'story case' in the beginning. So the method the book refutes is the method Winston Royce talked about back in 1970 and was later called Waterfall. Furthermore, Agile methods are used to get the project back on track. More on this in the post [Methods applied in the #NoEstimates book](https://smartguess.is/blog/methods-in-noestimates-book/).

This is not the first time the #NoEstimates proponents are using the Straw man fallacy, as can be seen by searching for ["#NoEstimates strawman" on Twitter](https://twitter.com/search?q=%23NoEstimates%20strawman&src=typed_query&f=top). This raises the question of why some key #NoEstimates proponents knowingly repeat false claims when they should know better?

### Why #NoEstimates proponents are knowingly making false claims?
Now, this is an interesting question. In one part, it has to do with spreading the #NoEstimates idea, selling books, and related consultancy services. Another part has a darker side, as many are trapped into believing the false claims and taking up the harmful and aggressive black-and-white stance on estimates, wasting a lot of time in unproductive arguments and causing polarization in our community.

### What's next?
In the next post, I will dive deeper into the purpose of repeating these false claims, keeping the polarization in our community rampant. The post, [Did you get caught in the #NoEstimates trap?](https://smartguess.is/blog/the-NoEstimates-trap/), shares an inconvenient truth about the methods we see used. 

**About Smart Guess** 
*We help teams educate stakeholders by providing actionable answers to common misconceptions about estimates. So more teams can use estimates to their advantage, and fewer are held accountable for delivering on impossible deadlines.*

Blog