Last week, I attended a free webinar by Mike Cohn of Better User Stories on the topic of “Write Better User Stories in Less Time With Less Aggravation”. Right after, I shared the replay link to some colleagues along with a few bullet points of pros and cons.
(+) interesting, maayos explanation
(+) ok din yung q&a
(+) insightful naman, gives you something to think about, stuff to google further
(-) promotional, the whole course is expensive $395
Posting my notes here since the learning from the webinar is something worth revisiting.
- Conduct a quarterly story-writing workshop
- Split stories to demonstrate progress even if the result is not truly shippable
- Strive to add just enough detail, just in time
Technique #1: Conduct a quarterly story-writing workshop
- Deliberate, focused meeting
- Brainstorm the stories needed to achieve the period’s most important goal
- Short-term focus causes teams to give in to what’s urgent over what’s important
- Team able to step away from day to day crisis… Without that big goal, the crisis always wins
Focus on a single objective
- “What shall we build?” — Wrong question, too broad, anything is fair game
- PO selects the significant objective (SO)
- SO typically achievable in about 3 months
- MVP, sometimes overused, seems can only be used once
- MMF = Minimum Marketable Feature = subset of overall feature that delivers value when released independently, smaller than MVP
Involve the whole team in writing stories
- Time investment, pays back on time savings when team works on the user stories
- They’ll have fewer questions later, they’ll have more context
- Fewer interruptions to devs’ day
- Devs may come up with better implementation, increased creativity
Visualize user stories with a story map
- Story maps invented by Jeff Patton
- Each card = 1 user story (1 thing the user needs to do)
- Horizontally = sequence of activities (don’t obsess over combination of sequence at this point, some steps may be optional)
- Vertically = alternatives (with most important on top)
Technique #2: Split stories to demonstrate progress even if the result is not truly shippable
- 90% joke – Ask dev how done are you and he replies 90%. Come back after a week, and answer is still 90%.
- Devs are not evil or liars, Estimating how done we are with something is notoriously difficult.
- In Agile, easier, no need to estimate. Just 2 states = Not started or Done
- 5 techniques for splitting stories (Lookup SPIDR), shared in the webinar were Splitting by Interface and by Rules
- When you split stories remember the goal is to be potentially shippable — (1) high quality, (2) tested, (3) what it does, it does well
Technique #3: Strive to add just enough detail, just in time
- Too much detail, too early vs Too little detail, too late
- Bad habit – want to know all before starting — when they do that they’re not doing overlapping work (analysis first, before coding, testing…). Overlapping work is central tenet in most Agile processes (that’s why we don’t have phases in Agile). Time to market gets stretched.
- Err on the side of too little, too late — you can improve by adding more detail next time
- Question 1 (during refinement or other discussions on a user story): Do you need the answer before you start on that story? Sometimes you need it before you finish work on that story, not before you start.
- Question 2 (during retro): Did we get answers just in time in just enough detail?
Reference / links:
- Webinar Sketchnote
- Mike Cohn’s Better User Stories
- Mike Cohn’s Mountain Goat Software (I think I’ve also linked to blog posts from this site at least once in previous posts)
- Webinar Replay Link (would be unavailable after Jul 30 EST but leaving it here just in case the slight chance they forget to put it down)