Tired of planning poker? Use some Emojination!! Cards free to download below:
Let me know your thoughts!!
“User story smells” is a term used by Mike Cohn in User Stories Applied. It describes anti-patterns that happen when writing user stories. Mike Cohn provided a number of story smells.
With 9 years Business Analysis experience, I decided to write my top 10 story smells. They are based on my observations. I’ve even created a game for people to try.
Smell 1 – Everything in a Sprint should be written as a user story
This seems to happen with less experienced agile teams. They use the story format for everything in a Sprint (e.g. As a developer … I want … So that).
Why is it bad? User stories are written from the perspective of end users. They ensure what you build is anchored on a user need. Technical tasks can be sub-tasks of user stories (preferred option), or just tasks that need to be done to keep the lights on (e.g. renew a cert).
User stories are one type of item in the product backlog. Other types of item include: bugs, tasks, epics and spikes. Item can be in a Sprint without being user stories. Don’t spend time thinking how a technical sub-task can fit into the user story format.
Smell 2 – Stories should be sliced by technology layer, because that’s how our development team will approach them
Teams can have different groups of developers (e.g. front end and backend developers). There can be pressure to slice stories accordingly, because each story will be done by a different development team. Another reason is that breaking it down by technology layer removes a dependency on other developer teams. This is an artefact of how the development team is split.
The problem with this approach is that technology slides do not produce a valuable deliverable for the end user. The front end slice must plug into the backend to add value. Vertical slices of functionality are preferred to horizontal technology slices. Vertical slices are much more likely to be potentially shippable.
Smell 3 – Stories don’t need acceptance criteria
This is a strange one – I’ve seen it before. The idea is that the BA/product team should not solutionise. They should present the user need/story to the developer and not come with a list of acceptance criteria/constraints.
The problem is – you need a clear outcome for a story. And there are often clear requirements from the business, or constraints to be considered. Just putting AS I … I WANT … SO THAT and leaving out the acceptance criteria means you won’t know when a ticket is done. It’s not specific enough.
Collaborative specifications, or collaborative specification reviews (e.g. 3 Amigos) work around this. Stories have to have acceptance criteria in order to be testable and closeable.
Smell 4 – The product owner is a user
One of the most common smells. The product owner is a proxy for the user, but 9 times out of 10 they’re not the end user of the service.
The user in a user story has to be an end user of the system. They can be personas/types of user (e.g. admin, front line staff, loyal user etc). Product Owners, BAs, members of the dev team are not the end users.
Writing AS A product owner I WANT something SO THAT value isn’t a user story.
Smell 5 – Acceptance criteria must specify how features look & behave
Some developers like lots of detail. And that’s OK … but generally speaking acceptance criteria specify behaviour (i.e. what the system does in certain scenarios). They don’t need to specify how it looks.
There can be times when describing how a feature looks is useful – or even necessary. Generally attaching a visual or link to a component library is sufficient.
A picture is worth a thousand words.
Smell 6 – System-wide NFRs should be written as NFRs
NFRs are tricky. There are obviously NFRs that affect the end user e.g. system availability. They can be convincingly been written in the user story format.
One problem with writing system-wide NFRs as user stories (e.g. availability, system backups) is that they cut across the entire system. It’s difficult to test these NFRs until the entire system is built. I prefer to have system wide NFRs either as “definition of done criteria” which get tested against each ticket, or as items for regression testing at the end of a release.
Story -specific NFRs might be written as ACs against a ticket (e.g. audit log for a reduction decision).
Smell 7 – Specifying what the user wants is enough!
I’ve seen several people excluding the 3rd line of a user story. It’s the reason why the user wants something – the 3rd line helps us to understand why we’re doing the work.
The 3rd line of the user story (So that … ) can be driven from user research, or observations, or data analytics etc. Either way we need to understand the why before we start to solve the problem. At the minimum a story needs to include “So that”. This helps with prioritisation.
Smell 8 – User stories should be incredibly detailed
User stories should specify the appropriate level of information. There’s a tendency from BAs, and sometimes from the development team, to try to put all the information they have into a ticket.
Having a ticket that is too detailed adds little value. It makes it likely that people will scan over the ticket and miss the most important information. An incredibly detailed ticket is not necessarily better than a less detailed ticket – it’s about having the appropriate level of information.
As a story is worked on it might be that more detail emerges. But a story should contain enough information for the team to develop and test it.
Smell 9 – User stories can depend on other stories in the Sprint
Ideally user stories should meet the INVEST criteria. That means each story should be independent.
Unless it’s agreed at Sprint planning & made visible on the ticket – all user stories should be independent. There may be cases where two dependent stories are brought into the same Sprint – however the goal should be that stories do not depend on other stories.
Smell 10 – Stories should be very small
This is more for teams that are using Gherkin & TDD, however some teams aim to have very small user stories. Almost at the level of a handful of scenarios.
One advantage of smaller user stories is that we can track progress in a Sprint to a more granular level. But a note of caution – small user stories are essentially a grouping of scenarios. They can make the Sprint board less manageable and in themselves deliver very little value to a user. For very small stories it is difficult to make them to be independent and valuable.
Here’s a link to a game we created. It lists the 10 smells + 10 example bad user stories. See if you can match them: https://docs.google.com/presentation/d/1MXP3IMv0s56_FemJ8f_srWdZXphKiUIFpfVT0bLG_aY/edit?usp=sharing
It’s a great team exercise – with either a product or a BA team. It helps reiterate some of the key points above. And makes examples tangible.
Any smells I’ve missed? Enjoy!
Like most Scrum teams, we held “Sprint Review Meeting” every two weeks. We would gather as a team to demo what was recently built & receive feedback. Although it was a great opportunity to showcase recent work, we identified a number of problems with “Sprint Review Meetings” for our mature product:
Build, Measure, Learn (BMLs) sessions
To address the above issues, we replaced Sprint Review Meetings with “Build, Measure, Learn” sessions. As advocates of the Build, Measure, Learn approach – we were keen to review recently released features with the team. We launched features every 2 weeks – so the natural cadence was to report on features at the end of the following Sprint.
We created “Build, Measure, Learn” sessions. The basic format is simple:
Every 2 weeks. At the end of the Sprint. Replaces the Sprint Review Meeting.
Team (Product, Devs, UX) & Stakeholders.
The session is divided into two sections:
The Measure/Learn section became as valuable as the demo section. It also provided practical breathing space for setting up/fixing demo’s – if we had problems we would start off with the Measure/Learn section 😉
As with the Sprint Review meeting – this section was the development team demoing what was built during the Sprint.
This was an opportunity for product/stakeholders to provide feedback and ask any questions. Changes were noted by the BA and put on the product backlog.
It was also an opportunity to praise the team & celebrate success.
In the Measure/Learn section the BA or Product Owner would cover the following areas:
We found that BML sessions were a great replacement to Sprint Review Meetings. They ensured we kept the measurement & learning part of the lifecycle front and center in the team. The Measure/Learn section also ensured we reported back on business value regularly.
“How Might We …” is a group brainstorming technique we have used for 6>months to solve creative challenges. It originated with Basadur at Procter & Gamble in the 1970s, and is used by IDEO/Facebook/Google/fans of Design Thinking.
“How Might We …” is a collaborative technique to generate lots of solutions to a challenge. Our team modified the technique slightly to ensure that we also prioritise those solutions. More on that below …
In essence “How Might We …” frames problems as opportunity statements in order to brainstorm solutions. For example:
How Might We works well with a range of problem statements. Ideally the question shouldn’t be too narrow or broad.
How Might We sessions involve a mixture of participants: product (Product Owner/BA), technical (Developers/Tech Lead/QA) and stakeholders. The duration is 1 – 1.5 hours.
The format is:
1. Scene Setup
Scene setup is about introducing the background, constraints, goals & groundrules of the How Might We session.
For example we held a session about: “How Might We get app users excited & ready for the Rio Olympics?” We invited 10 participants across product, technical and stakeholder teams. For 5 minutes we setup the scene. As part of scene setup:
2. Introduce the question
The How Might We question is presented to participants and put on a wall/physical board
The question shouldn’t be too restrictive; wording is incredibly important. Check the wording with others before the session. We circulate the question to participants ahead of the session – this allows them to generate some solutions before the meeting.
Framing the question in context/time will help. It makes the problem more tangible. For example:
“It’s 3 days before the Olympics. How Might We get users excited & ready for the Rio Olympics?”
Use a technique like crazy 8’s to generate ideas. Give people 5-10 minutes to think of many solutions to the question.
These solutions are typically written on post-it notes. At the end of 10 minutes we ask each participant to stand up and present their post-it notes ideas to the group. Participants explain their ideas; common ideas are grouped together. For example:
With 10 users you can generate 50 – 80 ideas. Once ideas are grouped together you can have 20 – 30 unique ideas.
We ask people to pick their favourite idea. It can be there own idea, or another person’s post-it note idea.
For 10-15 minutes they explore that idea in more detail. Participants can add notes/draw user flows/write a description about the idea.
At the end of 10 minutes, each participant is asked to present back their idea to the group. For example:
Once each participant has presented their idea (10 people = 10 ideas), participants are invited to dot vote. Each participant has 3 votes to select their favourite 3 ideas.
Typically this is where a HMW ends ….
BUT we would often find ourselves in a position where the top voted idea was the most difficult to implement. The top ideas were often elaborate & had a cool factor – but were very complicated to build/offered limited business value. For example: “We could build VR into the app. It would offer all sports in immersive 3D and recommend videos based on the user’s Facebook likes”.
AND we found that stakeholders weren’t comfortable having an equal say (3 dot votes) to QA/developers in terms of the product proposition.
SO we implemented a further step to converge on more realistic options. We took the top voted ideas + any ideas that stakeholders were particularly keen on from the How Might We session. We allowed UX to explore these ideas in more detail. An example of a more refined idea is an Olympics branded menu:
We took these ideas into the prioritisation session.
With the more refined ideas we held a prioritization session with the key stakeholders (product owner, tech lead, primary stakeholders).
As a group we would rank these ideas in terms of business value and technical complexity (1-5). The business value was driven by a KPI or agreed mission. The technical complexity was an estimate of effort.
Complexity 5 = hard
Complexity 1 = easy
Impact 5 = high impact
Impact 1 = low impact
We would end up with a relative ranking of the top ideas. For example:
The top left quadrant is tempting (high impact, low effort). The bottom right quadrant is not tempting (low impact, high effort).
We used the relative weightings & dot voting to select the best idea. We would go on to shape & build the best idea.
Within the Scrum Framework – there are numerous GASPs (Generally Accepted Scrum Practices). The following 4 meetings are all GASPs:
• Sprint Planning
• Daily Stand-up
• Show and Tell/Sprint Review
• Sprint Retrospective
There have been efforts to include a 5th meeting to the list of GASPs:
• Product Backlog Refinement (PBR session)
AIM OF THE PBR SESSION
The overall aim of this meeting is to manage the product inventory and ensure that the product backlog (i.e. anything outside of a Sprint) is up-to-date. This is done through the following PBR activities:
• Progressively breaking down large items (EPICs) into smaller items (features/use cases etc) that can be implemented in a single Sprint
• Grouping items based on commonality (technical delivery/product goal etc)
• Adding detail – such as acceptance criteria – to items in order to generate a common understanding
• Pre-Sprint, high-level estimation of items in the product backlog will facilitate delivery planning
• Methods include – story point estimation (e.g. planning poker on the Fibonacci sequence), t-shirt sizes, bucket estimation, blink estimation
• Items are prioritised according to business value (this is primarily identified by the Product Owner/stakeholders/user data)
• Items are independent as per the INVEST criteria – therefore the order of items on the product backlog leads to a prioritised Sprint backlog
IV) “Ready” state:
• Items are discussed – with issues/questions/actions being identified
• Agreement on what needs to be done in order to get items into “Ready for development”/”Ready for Sprint”
• Team understands the bigger picture – i.e. the vision beyond the current Sprint
• New, high-level user stories are discussed and added to the Product Backlog
• Bringing together members of the business and technical team to discuss ideation facilitates collaborative product development within a cross-functional team
GENERAL FORMAT OF THE PBR SESSION
• Regular – product priorities/understandings are dynamic. The product backlog must therefore be responsive to change. It is recommended that PBR sessions are held every Sprint or 2
• Scheduled – Typically mid Sprint in order to avoid conflict with the Sprint Planning/Show and Tell/Retrospectives
• Duration – Timeboxed – typically to 1.5 – 2 hours
• The Product Owner is primarily responsible for the Product Backlog. The Scrum Master is responsible for facilitation and the removal of obstacles. Attendance of both is therefore mandatory
• Team members – invited – however attendance is optional. Details of which stories will be discussed in the session should be provided in advance (this enables users to decide whether or not to attend)
• Small number of stakeholders can be invited to assist with prioritisation. Representation from both the business and technical team is preferred
• The entire product backlog is not discussed. Instead the agenda should cover items that are likely to come up in the next 3-4 Sprints
• The session should aim to achieve the following:
•• Agreement on story breakdown/high level definition
•• High-level estimation
•• Item prioritisation
•• Agreement on actions necessary to get items into a “Ready” state
•• Discussion of any new ideas
• At a high level – the aim of the PBR session is to ensure that items in the Product Backlog meet the DEEP criteria (Detailed Appropriately, Estimated, Emergent and Prioritised)