tl;dr: Well written user stories surface context, clarity, and priority and facility good conversation with the development team.
I think we've all seen the user story format that goes something like this:
As a team manager
I want to take notes on my team member's as I review their code
So later on I can refer to my notes while writing performance reviews.Fair enough. Pretty standard product management / product ownership type stuff. What follows is usually a bunch of acceptance criteria.
When I started with my current employer, I found myself in an interesting situation. My engineering team hadn't had a product manager in some time. They were mostly taking strong initiative to write their own stories and maintain their own backlog. While they perhaps didn't have access to company strategy, they certainly did a good job identifying good work to do and leaving adequate documentation of what they had done. I realized that one thing this particular set of engineers didn't need was the spoon-feeding of requirements. I started thinking of a format that would adequately express the what without meddling directly in the how of a task.
The major tweak I've made so far has been to express acceptance criteria in the MoSCoW format. Acceptance criteria fall under one of four headings: things the eventual solution must have, things it should have, things it could have, and things it won't have or things that engineers shouldn't spend time on now. This final category gives some indication of what might become rabbit holes, things to avoid, or things we are specifically deferring.
An example of my MoSCoW acceptance criteria looks something like this:
Acceptance Criteria
Must Have
- Team managers can reference a specific line of code and link comments to it
- Team managers can mark comments private so that only they themselves can read them
- Team managers can share comments that they have not marked private
- The coder who wrote the code (according to the blame function in git) can see comments about their code that are not marked private
Should Have
- Use existing web components and follow all UI conventions except where there's an important reason to deviate
Could Have
- Any little bells and whistles standard with this sort of function that I may have missed in the AC. Let me know and let's talk 🙌🏻
Won't Have
- Replying to comments. I don't think we want to invest the time unless the feature starts getting used. That can be a second iteration. Let's just get this going! 🙌🏻You see what I did there?
I left a lot of the decision making, within guardrails, to the engineer. Those guardrails are the drop-dead must-have requirements. To take this approach, you need proactive, thoughtful engineers. The approach is extremely helpful when they are motivated and know more about other parts of the product than I do. This story can also be handed first to a UX/UI person for mockups when appropriate.
Something else I'm considering is adding a bit of insight into how this story fits into broader corporate goals. These discussions really engage my teams. I imagine that encapsulating snippets of such thought into the ticket will not only provide more context but also more engagement with the company and our shared goals. I'm thinking something like this:
User Story
As a team manager
I want to take notes on my team member's as I review their code
So later on I can refer to my notes while writing performance reviews.
Why
We have received a lot of feedback saying that passing sticky notes is clunky and then handwriting the line numbers isn't effective because line numbers change so often. My hypothesis is that this work will make the code review system easier to use and clear a speedbump that interferes with adoption. This sort of context often provokes conversation. In those conversations, very good points are often raised that I hadn't anticipated.
"Hey Ryan, should we set up usage analytics to this? If so, what constitutes a 'use' especially if we don't have a save button? We don't use save buttons in similar features elsewhere."
😶
But actually, this feedback is very, very good, isn't it? This is a good conversation. Everyone engaged, thinking and solving together. Next step, back to the acceptance criteria.
In sum, our finished user story may look something like this:
User Story
As a team manager
I want to take notes on my team member's as I review their code
So later on I can refer to my notes while writing performance reviews.
Why
We have received a lot of feedback saying that passing sticky notes is clunky and then handwriting the line numbers isn't effective because line numbers change so often. My hypothesis is that this work will make the code review system easier to use and clear a speedbump that interferes with adoption.
Acceptance Criteria
Must Have
- Team managers can reference a specific line of code and link comments to it
- Team managers can mark comments private so that only they themselves can read them
- Team managers can share comments that they have not marked private
- The coder who wrote the code (according to the blame function in git) can see comments about their code that are not marked private
- Logging hooked up
Should Have
- Use existing web components and follow all UI conventions except where there's an important reason to deviate
- Logging is triggered when the manager leaves at least one word in comment box; if this causes problems, then we should explore adding an appropriately worded 'Save' button that triggers the logging.
Could Have
- Any little bells and whistles standard with this sort of function that I may have missed in the AC. Let me know and let's talk 🙌🏻
Won't Have
- Replying to comments. I don't think we want to invest the time unless the feature starts getting used. That can be a second iteration. Let's just get this going! 🙌🏻I've recently learned that this approach is used in some software shops. That's cool. I'm going to go ahead and chalk this up to "great minds think alike."
Do you do anything unusual to help bring context, clarity, and priority to your user stories?