What I liked about it
  • The interaction part with the user story estimation
  • Having an exercise in it
  • Idea of estimation with stakeholders
  • Practical, example give to tryout
  • Lively speaker & new concept of 'round trips'
  • Good interesting topic for discussion
  • Enjoyed the pretend conflict dev/product owner
  • The idea of using round trips as a measure for complexity
  • Practical demo of
    • Involvement (taking turns)
    • Categorizing use cases
  • Opportunity for participants to share ideas
  • Value of upfront interaction very clear
  • Estimation with product owner and developers in a workshop with a lot of interaction
  • Interactive, practical
  • Going circles to estimate
  • The "life" example
  • The discussion
  • I learned a new tool to estimate and I will use it!
  • I like the practical session because it makes clear the technique
  • Nice technique, good idea
  • Useful! Simple technique (easy to remember)
  • Good alternate engaging tool
  • Interesting concept
  • Interesting perspective on estimation
  • The concept of involving the customer in the estimation
  • Useful ideas for smaller projects, or versions of larger programs
  • Interesting new point
  • New idea
To improve
  • I would like to learn how you estimate epics at the start of a project. I did not see how you would do that.
  • Pace of delivery
  • Make exercise more practical (fast)
  • Link back to budgeting/project planning
  • Too much time and discussion on detail in example. Even though it was a workshop.
  • More on uc transactions and results.
  • And where is the budget and planning?
  • Something about the speed/energy
  • Lots of text on the slides: change to graphics
  • Divide participants to the workshops in stakeholders and developers
  • Guide better the simulation to focus on interaction
  • Insert a slide to say when you should use the "early estimation" (ex. After backlog definition)
  • During the discussion also make sure that not only the people of the exercise are discussing but also the other audience members
  • Title was a bit confusing with the explication
  • Clearer explanation up front
  • Sides too full of text: add images and simplify the visuals
  • Add a better example for the concept of "use case points" - it was presented too quickly
  • Not sure about the validity of the method
  • Rethink exercise
  • Other build up
  • The method of transaction counting was not really used during the estimation session
  • Clarify how round trips/points are translated into estimates for budgets
  • Include where these initial "user stories"/use cases came from
  • As a product owner, don't tell too much! Only tell what you are asked
  • The other presenter could coach the "developers" to ask more questions
  • Write the estimation parts/interactions
  • Don't let the session get hijacked
  • Pick a title that covers the subject better
  • Design the exercise so that all the attendees can take part. While this was going on, the presenters were only really talking to the volunteers at the front of the room. The examples didn't really work for me.
  • I agree with feedback that this is more suited to small projects than large projects. More discussion on this please.
  • Change title since it's not that early
  • Shorten the exercise, too long
  • Does not feel that it would work with team and stakeholders, make more role play in exercise.
  • Change title to "sprint planning"
  • Make it real and put money on it
  • I didn't buy in to practicing it because there are too many details missing like: how detailed do you go, how do you process to money estimate
  • Make it a 90 min. session
  • Smaller demo
  • More details and background
  • Less time for exercise that adds little value