New App: Make The Estimation Process Simpler And More Inclusive


Userlevel 3

Hi Miro Community,

 

We’re so excited to let you know that the Estimation app is now available to all users on paid plans! 

The estimation process is designed to help your team predict the amount of effort required to bring a project across the finish line ― often used in Agile product development practices. 

Our new Estimation app lets you add more to structure the process, increase the accuracy of your estimates, and gives everyone a voice with votes. 

  • Create Miro sticky notes and cards, or bring Jira development tasks onto a Miro board to make it easier to estimate, and add design files or diagrams for more visual context

  • To make the estimation process more inclusive, give everyone an opportunity to cast a vote, empowering individuals and sidestepping the bias of group thinking

  • Once voting is done, you can start an agreement session to go through results and focus on the tasks where team members disagree

  • Remove the hassle of manually updating estimates in Jira and sync them with the click of a button

Visit this Help Center article to learn more and don’t forget to let us know what you think once you’ve tried it! 

 

Happy estimating,

Jenny


19 replies

Userlevel 7
Badge +6

@Jennifer Yzelman -

It’d be great if the following changes were made to the cards:

  • Replace 21 with 20 - normal estimating poker decks round up the numbers after 13
  • Add a 0, ½, 40, 100, infinity and coffee cup card

Also, I wasn’t sure about this but can you have multiple simultaneous estimation sessions going on at the same time on one board or is it a single active session per board? The reason I ask is that when I teach this technique in classes I might have 3-4 groups and each would be sizing their work items separately from others, all on the same board.

Kiron

Thanks for your feedback, Kiron! I lead Miro’s product teams in this area and it’s always great to hear from our users and community members.

It’d be great if the following changes were made to the cards:

  • Replace 21 with 20 - normal estimating poker decks round up the numbers after 13
  • Add a 0, ½, 40, 100, infinity and coffee cup card

More estimate types and custom estimates are things we’re actively considering. What do you use the coffee cup for, out of interest?

 

Also, I wasn’t sure about this but can you have multiple simultaneous estimation sessions going on at the same time on one board or is it a single active session per board? The reason I ask is that when I teach this technique in classes I might have 3-4 groups and each would be sizing their work items separately from others, all on the same board.

Much like with our voting app, you can only have one session per board at a time. Would you be able to use multiple boards for this, or is there another constraint that prevents this?

Userlevel 7
Badge +6

@Peter Parkes -

  1. The coffee cup is a signal which a team member would use to let the team know that they’ve been estimating for long enough and its time for a break (coffee or otherwise)
  2. Multiple boards could be used but its a kludgy solution as I’d need to direct learners to go to a different board specifically for their breakout team and then come back to the main board. I’ve found that multiple boards tend to create a lot of confusion for learners. I’ve used links to make it easy to go from one to the other but it still isn’t as easy as doing it on a single board.

Kiron

The coffee cup is a signal which a team member would use to let the team know that they’ve been estimating for long enough and its time for a break (coffee or otherwise)

Got it – thanks! The way we’ve built the app also allows for asynchronous ‘voting’, and then synchronous agreement. You can start the process and let people vote in their own time, and then get together to discuss and agree estimates.

 

Multiple boards could be used but its a kludgy solution as I’d need to direct learners to go to a different board specifically for their breakout team and then come back to the main board. I’ve found that multiple boards tend to create a lot of confusion for learners. I’ve used links to make it easy to go from one to the other but it still isn’t as easy as doing it on a single board.

Very clear – thanks!

Userlevel 4

@Peter Parkes  The opportunity for asynchronous voting is a great enabler here. Already provided this feedback before but I think that whomever initiates the voting session should have the ability to enable anonymous voting or by username. This way there is a choice. I can see both sides of the argument as to why anonymous and why some would prefer transparency.

I think that whomever initiates the voting session should have the ability to enable anonymous voting or by username. This way there is a choice. I can see both sides of the argument as to why anonymous and why some would prefer transparency.

We’re exploring some options for more configurability here – thanks again for the feedback!

I love this for cards. Are there plans to let kanban templates total estimation points rather than count stories? That would be a gamechanger for us.

Userlevel 4

@Jasmine Friedrich that would be an interesting update to the Kanban function in MIRO if it was able to total based on SP.

I love this for cards. Are there plans to let kanban templates total estimation points rather than count stories? That would be a gamechanger for us.

Thanks! We’re actively looking at potential improvements to the Kanban widget for planning/estimating/capacity measurement purposes. Stay tuned!

+1 on allowing 

In a virtual form, I’d like to propose an option for folks that could speed up the discussion and consensus process… how about adding a text field (optional!) to the voting panel, with the question “Why?” as a label. Then people could, for instance vote “0.5” and in the Why box, enter “This would take me two minutes - it’s a one line change.” 

Usually we would ask for the numbers blind, and then have the discussion about why… seems this might give the group a running start at understanding the votes faster than having the first pass discussion. 

For bonus points, maybe the votes and “why” comments could optionally be stored in a comment in Jira once voting completes? Then the team would have an automatic record of the reasoning, without having to transcribe or convert to notes…

Here are a few more thoughts on allowable point values.

I agree that some teams like to have 0, and ½ (0.5) as option. 

While the community (myself included) talks about using a fibonacci series for planning poker, there’s an urban legend (I don’t have proof of this) that some early practitioner created a set of planning poked cards using “pure fibonacci” - ie 21 included - and then copyrighted the cards, so people decided to go to 20/40/100 instead, rather than having some future copyright issue. 

While I suspect that legend isn’t fully true, almost all teams I’ve worked with over a couple of decades use the sequence 8/13/20/40/100 for larger scale estimates. 20/40/100 almost always indicate “this is various levels of huge, and I might be scared to even estimate it,” but having those reactions available is useful in the estimate discussion process. 

Alternate use case: This sort of estimation is also used for epics / larger scale work before stories are created… and in those cases the numbers can be much larger, into the hundreds of points with real estimation values. 

Here’s a proposal: Enable a standard estimation series, geared around points for stories, using the pattern: 0,0.5,1,2,3,5,8,13,20,40,100, and as an option, allow people to create their own estimating series (for larger work, or for people who “just don’t like the commonly used pattern.”

It seems this would give solid guidance for people who don’t have a specific preference, allowing for industry norms, and then also allow for other cases where other numbers would be a better fit. 

Curious for thoughts about this...

Can it count the total votes? (sum of votes on all cards / all cards in a region). This is an absolute necessity for me. Otherwise, we’ll continue to use Excel or Jira for this...

Custom estimates please! Silly to try to force Fibonacci on everyone. Please allow estimation pre-sets to be configurable by board, or configurable at estimation time by voters. 

Please add to the backlog:

As a facilitator I have the ability to use preconfigured “mode settings”:

  1. “Learn Mode” w available sizes: modified fibonacci series
  2. “Predict Mode”  w available sizes: 1, TFB, NFC
  3. “Ludicrous Mode” which allows, no enforces, two decimal places of precision on learn mode


    JK about #3. Replace that w “timebox for enabling ‘Learn Mode’ to 3 iterations. Then only available option is #2.”
     

    Don't worry about getting better/more accurate at "estimating"

     

    Instead:

  • Get better at asking "can we make this any smaller?"
  • Limit WIP (finish before starting)
  • Make "Flow" more efficient (doing time vs waiting time)
  • Reduce/ eliminate dependencies
  • Swarm on impediments
  • Work in pairs/ensembles more

 

Dear Miro Team,

I suggest to rethink the necessity for an estimation feature. For a couple of years now there is an ever-growing share among “leading” agile coaches and developers who argue against estimates that surely you also have come across. Let’s mention Kent Beck, Ron Jeffries, Allan Holub, Tom Ottinger, Alistair Cockburn, J.B. Rainsberger, Vasco Duarte, etc. to name just a few.

 

Estimates aren’t necessary for being agile and they don’t contribute to become more agile. What I have observed so far is that whenever teams estimated their work these estimates sooner or later leaked to management and were there taken at face value - with all the subsequent hassle one would expect. This is harmful to teams.

Jira has been offering estimates for years and recently - giving in to pure ridiculousness - also introduced decimals for estimates. As if estimates are some sort of scientific measure. They are not. Virtually all other task management tools do the same. But Jira and many colleagues are not a tool well suited for agile teams. Full disclaimer: I once was also strongly in favor of estimates and even took video courses from Mike Cohn on how to improve estimates. Improving estimates is not valuable work. Estimating is not valuable work either.

The “inventor” of Story Points, Ron Jeffries, is even slighty sorry for inventing them given how points are being misunderstood and misused in modern SW development: https://ronjeffries.com/articles/019-01ff/story-points/Index.html

 

Miro has been my favorite tool for workshops over the last four years or so and introducing estimation will not change that. Yet I would advocate to NOT become another task management tool.

Dear Miro Team,

I suggest to rethink the necessity for an estimation feature. For a couple of years now there is an ever-growing share among “leading” agile coaches and developers who argue against estimates that surely you also have come across. Let’s mention Kent Beck, Ron Jeffries, Allan Holub, Tom Ottinger, Alistair Cockburn, J.B. Rainsberger, Vasco Duarte, etc. to name just a few.

 

Estimates aren’t necessary for being agile and they don’t contribute to become more agile. What I have observed so far is that whenever teams estimated their work these estimates sooner or later leaked to management and were there taken at face value - with all the subsequent hassle one would expect. This is harmful to teams.

Jira has been offering estimates for years and recently - giving in to pure ridiculousness - also introduced decimals for estimates. As if estimates are some sort of scientific measure. They are not. Virtually all other task management tools do the same. But Jira and many colleagues are not a tool well suited for agile teams. Full disclaimer: I once was also strongly in favor of estimates and even took video courses from Mike Cohn on how to improve estimates. Improving estimates is not valuable work. Estimating is not valuable work either.

The “inventor” of Story Points, Ron Jeffries, is even slighty sorry for inventing them given how points are being misunderstood and misused in modern SW development: https://ronjeffries.com/articles/019-01ff/story-points/Index.html- geometry dash

 

Miro has been my favorite tool for workshops over the last four years or so and introducing estimation will not change that. Yet I would advocate to NOT become another task management tool.

Thanks!

Thanks again for all of your feedback – some great suggestions in there and we’ll factor these in to our planning for future improvements.

 

Christoph – thanks for your comment about estimation as a concept. We aim to support a wide variety of working processes and styles, and recognise that different people value different parts of the Miro experience. Workshops are super important to us and that area of focus isn’t going to go away!

Hi Jennifer
thanks, good idea! Would like to add Azure DEVOPs sync, additionally to Jira to your roadmap.

Expectation easy sync between DEVOPS and Miro: I can drop some PBIs to Miro, do the estimation and best case the estimation appears in DEVOPS. Do not know, if this is possible at all, but that would be my usecase...

Best regards

Reimar

Userlevel 3

Thank you for your feedback @Reimar

This is something that we’ll definitely look into.

As for Azure DevOps, did you know that we recently released the two-way sync? Now you can easily create and edit Azure DevOps work items directly from Miro, and turn sticky notes and Miro cards into Azure cards. No need to worry about manually updating tasks and information in two places: all changes are automatically reflected in both tools ― whether you make them from Miro or Azure DevOps. More information can be found on this help center article. 

Reply