Have you ever wondered does this User Story thing really help my team?
So another day and I'm planning user stories in Jira with my Dev-lead and we are wondering how to setup our next few sprints of work when we just finished a project that's been going on for 8+ months.
Principle 1: "The Quarterly Story-Writing Workshop"
3 months is a good rule of thumb for the amount of stories you can write or layout up front.
If I schedule and write stories too far out in the future: ? ("too much")
- ? my developers forget the details and I've got to setup meetings to review the stories.
- ? I might end up promising to much to the customer when we haven't gone through tech design.
- So if I need to I'll write some epics (especially for things way out in the future)
If don't schedule more than a sprint's worth of work: ? ("too little")
- I have a lot of cards and tasks to follow up on and my life gets really busy
(I have two developer teams with multiple products so that's a no go)
- My developers get antsy about what is coming next.
My current rule of thumb is 3 sprints out should be clear in my Dev-leads mind, and I should be clear about the 3 month pipeline. The Dev-leads meet with me and we discuss our bigger picture occasionally, but for the most part, I don't want them digging in on those details until they are ready. I want them focusing on the team and the technical details just in time.
? ("just right")
The big kicker: Setting up a User Story Mapping Session with my product managers. Setting an expectation with my customer to do multiple meetings and dig in on the jobs to be done concept is really helpful. When I set an expectation that I need some committed time from them to get a decent product I find we get more value. The other plus is I can get in and out and I'm not constantly hitting up my busy product managers for their time.
My high-level cards are the behaviors we are trying to address or the pain-points. Then from their I can break it down into smaller user story cards.
"Significant Objective Focused on One Goal"
Having a specific focus on the behavior, pain-point or key objective helps us stay focused on delivering a shippable or releasable nugget of value to our customer.
"Master the Art of Splitting Stories"
My rule of thumb is 2-3 days is the max a length a story should go unless its a spike and my dev is doing research.
"Just Enough Detail, Just In Time"
- Looking at stories every sprint or so, Fire / Emergency
- What is important is seldom urgent ⭐
- What is urgent is seldom important ??
- Worse if new user stories each iteration (I like a bit of stability)
- Creates a temptation
- Stakeholders get dissatisfied
- Dev gets discouraged
- People start doubting: Agile benefits
- if the product group has defined what to such an extent that the tech team's input isn't really needed:
- then you're telling them what to build and kinda wasting time
- by not being collaborative about it and might as well have done an upfront requirements doc
The Key Takeaways
- ? Write user stories less frequently
- Balance between Too much detail, Too Soon and Too Little Detail, Too Late
- On later stories, add more detail until you've got it right, problems are so apparent
- Do you need the answer before you start on that story?
- Did we get answers just in time in just-enough detail?
Here's a link to Mountain Goat Software's great handout on writing better user stories webinar. Download PDF link.
I'm going to their Scrum training next month virtually looking forward to it.
Enjoying these posts? Subscribe for moreSubscribe now
Already have an account? Sign in