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

Many ask why estimate using story points and not time? Everyone understands time. Why introduce story points and relative estimates? Let's cover the key reasons why story points work better.


### 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.

**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.


Story points: Why not use time?

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

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

People new to story points ask questions such as:
1. How do you convert 3 story points to hours?
2. How is the mapping from story points to days?
3. How do we convert story points into duration?

This post answers how, so your team can focus on delivering results.

## 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

Converting story points to hours - how does it work?

small_SmartGuess-add-card-step.2.png

thumbnail_SmartGuess-add-card-step.2.png

SmartGuess-add-card-step.2.png

Inspired by a customer question earlier this week, users can now fully configure Card deck values and the Timer in Smart Guess. 

Here is how it works and how you update to the latest version.

large_Screenshot 2022-03-21 at 14.10.44.png

medium_Screenshot 2022-03-21 at 14.10.44.png

small_Screenshot 2022-03-21 at 14.10.44.png

thumbnail_Screenshot 2022-03-21 at 14.10.44.png

Screenshot 2022-03-21 at 14.10.44.png

## Updating to the latest version
This is a minor update and is automatically made available. However, the previous update since the 7th of March 2022 was a major update and requires two steps to install. 

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)



Card decks and Timer now fully configurable 

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

Pushing for a lower estimate is like negotiating for a better weather with the meteorologist! The meteorologist doesn't control the weather and therefore the negotiation can't improve the time to deliver.

Let's cover the reason why and how to turn the discussion towards a more productive dialog. 


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_why_#NoEstimates_Took_Off383473585.jpg

medium_why_#NoEstimates_Took_Off383473585.jpg

small_why_#NoEstimates_Took_Off383473585.jpg

thumbnail_why_#NoEstimates_Took_Off383473585.jpg

why_#NoEstimates_Took_Off383473585.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

Looking at the #NoEstimates & Estimates discussion today. It is clear polarization and division have overtaken the dialog. There is a reason for this. Because there is evidence, it is being manufactured and maintained on purpose. 

It might come as a surprise to many. But you might have fallen into the #NoEstimates trap, unknowingly adding more fuel to the fire!

In this post, I will cover the methods used. And discuss how we can move beyond the polarization and the grim future it holds.

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'

large_Relay-race_shutterstock_1172355169.jpg

medium_Relay-race_shutterstock_1172355169.jpg

small_Relay-race_shutterstock_1172355169.jpg

thumbnail_Relay-race_shutterstock_1172355169.jpg

Relay-race_shutterstock_1172355169.jpg

Cut your sprint planning estimation in half compared to the rest. How is that possible, you might ask? Following critical insights based on user research in the field, we noticed users of existing planning poker tools feel they slow down the process. 

A different approach was needed to simplify the way current tools work. Customer reviews are promising, "The most efficient..", "Lightweight," "Intuitive," and "out of the way."

large_Smart Guess - Planning Poker with physical planning Poker cards.png

medium_Smart Guess - Planning Poker with physical planning Poker cards.png

small_Smart Guess - Planning Poker with physical planning Poker cards.png

thumbnail_Smart Guess - Planning Poker with physical planning Poker cards.png

Smart Guess - Planning Poker with physical planning Poker cards.png

#### Observation: Only a tiny part of sprint planning is estimating
The picture shows the estimation steps are only four, the green cards. In total, there are thirty cards, which means only a small part, 13% of the whole process is about estimation. This makes sense because the key outcomes of sprint planning are building shared understanding and making good decisions on how to proceed.

What follows is that good tools keep this in mind allowing teams to focus on the most critical outcomes rather than taking center stage and getting in the way. 

Let's walk through Sprint planning using a tool such as Jira and physical Planning Poker cards, to understand the baseline, looking at the process outlined above.

#### 1. Sprint planning starts
When sprint planning starts, the team shares a screen showing the backlog, allowing them to move through the backlog, discussing stories in priority order. 

#### 2. Discussing a story
When discussing a story, before estimating, the team needs sufficient clarity. In general, the discussion is about three things:
1. **Value** - is value for the user clear?
2. **Feasibility** - is clarity on story implementation technology-wise?
3. **Usability** - is clarity on design and user experience?

#### 3. Key actions noted
The story is kept up to date during the discussion by recording key decisions and action items. Once sufficient clarity is in place, the team moves into estimating. 

#### 4. Estimation
With everyone at the same place, with physical planning poker cards in hand, it's easy to run estimation using the Planning Poker method:
1. Each team member decides on an estimate
2. Team members share their estimates
3. Discussion on differences takes place - moving back into updating the story - if the discussion calls for it
4. The team decides on an estimate
5. Updates the story point value

The meeting continues, once all stories have been discussed and estimated, team members break the stories down as needed, in line with the Scrum guide, topic three, How will the chosen work get done?

#### Where does this process break down?
Overall, this process works quite well. However, it breaks down when team members can't share the same room and try using tools vastly complicating the workflow, as the following user explains:

> "My teams have been struggling with estimation tools, especially remotely. We've tried everything from pointing on fingers to cards to post-it notes to third-party tools with little to no success."

Let's look into the job steps for current tools in comparison.

## How first-generation Planning Poker tools are wasting your time
We can see where things get complicated by mapping out the job steps using the same approach. Note that 'Step 1 - Making stories ready for planning' is the same. However, 'Step 2 - Setup the Planning Poker tool' is where things get complicated. 

large_Smart Guess - Planning Poker with 1st Gen Tools - Part 1.png

medium_Smart Guess - Planning Poker with 1st Gen Tools - Part 1.png

small_Smart Guess - Planning Poker with 1st Gen Tools - Part 1.png

thumbnail_Smart Guess - Planning Poker with 1st Gen Tools - Part 1.png

Smart Guess - Planning Poker with 1st Gen Tools - Part 1.png

large_Smart Guess - Planning Poker with 1st Gen Tools - Part 2.png

medium_Smart Guess - Planning Poker with 1st Gen Tools - Part 2.png

small_Smart Guess - Planning Poker with 1st Gen Tools - Part 2.png

thumbnail_Smart Guess - Planning Poker with 1st Gen Tools - Part 2.png

Smart Guess - Planning Poker with 1st Gen Tools - Part 2.png

#### #1. Problem - Setup the planning session
You need to set up an 'estimation game' using first-generation tools. Some tools have as many as eight different fields just to get started.

#### #2. Problem - Create and manage a copy of your backlog 
 With the first-generation tools, users are making a copy of the stories they will be covering. Once a copy is in place, they need to manage two lists; the backlog and its partial copy, the 'estimation backlog.'

#### #3. Problem - Found missing a story? Extra work for you!
What happens when you identify a missing story? Frequently this occurs when preparing or during sprint planning. When managing two lists, you need to first create the story in the backlog and then add it to the estimation backlog.

#### #4. Problem - Sharing the 'estimation backlog' with the team
 Some tools need you to fill in team members' emails to share - as if calendar apps or Slack didn't exist. 

#### #5. Problems - Stories in the 'estimation backlog' are missing info 
Once teams open the 'estimation backlog' and start estimating a story, key information is often missing. This is because these stories present only a limited set of information. Meaning you can't quickly bring up an important attachment, comment, etc. You first need to open the Jira issue.

#### #6. Problem - Updating stories in the 'estimation backlog' is further away
Using the 'estimation backlog' and discussing a story. When the team needs to update a story, you can't easily do that. This is because stories in the 'estimation backlog' present only a limited set of actions. Meaning you first need to open the Jira issue to update the story.

#### #.7 Problem  - Updating story points in Jira isn't a simple action anymore
Saving estimates is more complicated. Using tools not integrated with Jira means you need to update all issues you covered manually. Many tools with Jira integration have an overly complex way of saving estimates. See the job map for more examples. 

#### Comparing the two approaches side by side
There is a stark difference between the two, mainly because of two things. First, you need to set up the first-generation tool every time you use it. Secondly, you need to move back and forth between Jira and the planning poker tool during planning to get things done.

large_Comparing-2-PlanningPoker-Tools.png

medium_Comparing-2-PlanningPoker-Tools.png

small_Comparing-2-PlanningPoker-Tools.png

thumbnail_Comparing-2-PlanningPoker-Tools.png

Comparing-2-PlanningPoker-Tools.png

## What kind of solution works better?
Seeing the Sprint planning process mapped out side by side, it is clear how the first-generation tools recreate parts of Jira, introducing complexities and extra work for users. Smart Guess takes a different approach and builds on Jira's strengths. Adding functionality teams are missing to run remote Planning Poker estimation effectively within the Jira backlog.

As can be seen by comparing the three approaches below, Smart Guess takes the same approach as planning poker with physical cards:


large_Comparing-PlanningPoker-Tools.png

medium_Comparing-PlanningPoker-Tools.png

small_Comparing-PlanningPoker-Tools.png

thumbnail_Comparing-PlanningPoker-Tools.png

Comparing-PlanningPoker-Tools.png

## Cut your sprint planning estimation process in half
Moving away from existing tools means:
1. No 'estimation game' setup - just get your backlog ready for planning, no time spent creating and managing an 'estimation backlog.'
2. Planning and estimation solely from the Jira backlog - allowing the team discussion to flow naturally between story discussion, estimation, and updating stories 
3. Run remote planning poker as if co-located

It also means teams now use the best tool for Sprint Planning - the Jira backlog! Here is a short video showing how Smart Guess for Planning Poker works:

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

Smart Guess is available on the Atlassian Marketplace for Jira Cloud. It takes only a minute to install, only few minutes to see how it works and saves time every sprint.
 
[Try Smart Guess today](https://marketplace.atlassian.com/1225496) and see for yourself how you can improve your sprint planning process.


Are you wasting your time on outdated tools?

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.

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

Although the idea here is to add the custom field directly to the Jira Backlog - line item, as can be done on Jira Server, this is not possible on Jira Cloud at the moment. However, Atlassian this this on their roadmap, and we will let you know when it's live.

In the meantime, here 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 you 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" 
![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

Many taking part in the #NoEstimates discussion from both sides agree the dialog is often unproductive. One part of what fuels the fire is #NoEstimates proponents who take an aggressive black and white stance on the topic, claiming estimates are always bad. In this post, we answer why taking this stance is harmful and what is the impact on our community. Before closing I will ask what is the purpose of repeating these false claims, keeping the polarization rampant.


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 are supporting your cause. Followers look at 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 might you 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 can be 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. Lots of comments and lively discussion. 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 back in 2016 and is highly active on Twitter under the #NoEstimates hashtag. Nearly every day, Vasco is posting 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 actually 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 through his tweeds looking for other similar statements, Vasco is saying *estimates never work*.

**That is a bold statement.**

Why? Because logically making this claim means it takes only a single case, one example, where an estimate is used successfully to show statements making this claim are false. Here is a post [Debunking the statement' estimates never work'](https://smartguess.is/blog/debunking-estimates-never-work/) showing these kinds of 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 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.*


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

When looking for answers to why many claim estimates don't work, I came across the author of the #NoEstimates book. In the book, there is a section stating estimates work, while "estimates never work" is commonly shared by the author under the #NoEstimates hashtag.  In this post, I debunk estimates never work. Furthermore, ask why few key #NoEstimates proponents are knowingly making false claims.

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_Straw-man.jpg

medium_Straw-man.jpg

small_Straw-man.jpg

thumbnail_Straw-man.jpg

Straw-man.jpg

The straw-man fallacy is used repeatedly by few #NoEstimates proponents to dismiss the value of estimates. In this post, we will look into examples of this fallacy. In addition, we will also see how the straw man fallacy is the backbone of the #NoEstimates book. 

Blog