[HCM Scrum Breakfast] Agile estimation - Story points

Editor's Notes

• #2: Zoom x3 My name is Pedro and I am currently Scrum Master at TINYpulse Been working with 3 teams so far One of the most difficult part is to understand points
• #3: You don´t like your manager We have the deadlines - it´s stressing From SW dev to FOOD & Beverages You start as a waiter
• #4: Your boss comes “I need you to tell me how long you need to move all these glasses Can you come back in 10 mins?” You need a tool → TRAY Have an estimation of how many trays is that After 30 minutes, see how many trips you have you done → Calculation Why did we do that this way? → We inspect first, and adapt
• #6: What’s a story point? “An estimate of relative complexity of a user story”
• #7: It compares how much you thought you can finish VS how much you actually finish Estimate is not a commitment
• #8: Volume → High intensity tasks (like localization) Complexity → Number of cases, possible interactions, many user profiles Uncertainty → We don’t need all details Best estimators are QA → Because they focus on complexity of the story, and not SPECIFIC TASKS
• #9: Human being tends to be optimistic Just like the trips for the waiter before Why can’t we add hours estimates? Elaborate Because it makes people think that it will be done in X weeks It doesn’t factor in side effects (like events, bank holidays, etc.) 80 hours → 2 weeks Explain the example of 2 runners making a 5 kms trial In 10 mins / 15 mins
• #10: The important point is the AGREEMENT
• #11: Split into groups - 3 minutes
• #13: 2 Rounds How many times is Portugal contained in Spain? KM2 RELATIVE
• #14: Who got around +- 20,000 Who got 5?
• #15: Talk about Simula company Norwegian company
• #17: Joke about the estimation by kilos from spec book
• #18: B - Maybe no work involved C - Buffer for later requirements
• #19: And the funniest thing is that they were asked if the customer estimation influenced them
• #22: That’s how it works normally
• #23: When the team is discussing a LONG TIME , getting LARGE and LARGE Stop and ask, “What’s the simplest version that can possibly work?” Capture that simple version as its own story Break out all the variations and complexities into their own stories.
• #24: Mike Conh wanted to challenge their teams about ways of estimations They started using just numbers They complained about long discussions 14 or 15??? One came up with the idea that they don’t use those numbers Long discussions
• #25: Then the numbers would be considered like buckets → Implicit buffer
• #26: But the buffers were too big specially for big numbers A bucket of 13 kilos can hold 14-15 kilos of sand
• #27: Because a PO asked why a 21 specifically → You must be into something! Because fibonacci! → (fibo what?)
• #29: For more EXPERIENCED teams
• #31: As a PO, you can get 2 questions When will I get THIS done?
• #32: What will be done by the end of sprint 7?
• #34: If you get these stories too frequently, you should ask if your team is really cross-functional Talk about mobile guys in the team
• #36: PO can’t just go and say “Make this part better” But there are other cases like design tweaks that you can still assume the worst
• #37: McDonalds has burguer for 5$, and chips for 3$ However the Combo is 7$
• #38: Present stories Let the team sort them by the swimlames
• #39: Story triangulation
• #41: I hope this can improve your teams doing estimations Talk about all my learnings