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
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 finishwork on that story, not before you start.
Question 2 (during retro): Did we get answers just in time in just enough detail?
This morning’s read tried to capture the job of a PM into 4 words: “Figure out what’s next.” I think in the work we do in building software (regardless of what your role is in your Agile project), we have to do a lot of figuring out. Coming with ideas or solutions independently is so important, and so is working collaboratively to further refine those solutions. Although it’s important to differentiate when it’s collaborating from spoon-feeding or unnecessary hand-holding.
Anyways, the post also enumerates 7 core skills to build for the Product Management role (actual text from the post are in bold, elaborations that follow are mine). But regardless of what role you are in the project, I think these contribute to being a good team player.
1. Taking any problem and being able to develop a strategy to resolve it — When you’re in the business of building software, figuring things out (preferably independently, with little to no hand-holding) is a critical skill.
2. Executing, getting shit done — *in any role, this is valuable*
3. Communication — *same… in any role, you need this*
4. Leadership through influence
5. Making decisions, informed by data
6. Building great products, and having taste — As PM/PO/PPO/BA, you work closely with your designers. I think you also need to brush up on UX so that you don’t undo any of the good work your UX designers present to you for your feedback.
7. Always be prepared — *important for any role* I like the quote the author shared.
[Great PMs] say what they’ll do, and then do what they say. Their follow-through is impeccable, and they don’t let details slip. When they join a team, quality and pace seems to dramatically improve overnight. — Noah Weiss
And I couldn’t agree more with his recommendations for developing your “I got this” aura. Over the years, I’ve worked with a few folks who would sound like they’re so unsure of what they’re doing. It just doesn’t bode well — it doesn’t give the team (or worse, their stakeholders) confidence that they’ll get the work done. I mean it’s OK to admit that you don’t know everything, because no one does — even “experts!” And it happens, I’ve gotten into countless of interactions where I really have no idea on what to do. But I guess my confidence (or my display of not panicking) stems from knowing that I have the capability and means to figure it out. (And that it’s not the end of the world if I don’t.)
So anyways, I’ve rambled on. Go check the post for the recommendations!
Super quick background: Our project started Jan 2015. To kick things off on the Agile methodology, our Scrum master conducted a brief training (less than half a day) to the team, and we’ve been playing it by ear ever since.
Over the course of many sprints, retros and releases, we’ve made adjustments on how we’re doing Agile. I’m not sure if there are Agile Purists who would frown down and shake their heads at us for the variations we’ve made. But the thing is, despite our possibly non-canon approaches, what still matters most is the team closely working together to deliver working software.
This post might be TL;DR. But in case you’re still interested in having a peek at how our little team does Agile Scrum, go on and have a read…