SHEQC grooming enables teams to groom a complex user story in less than 45 minutes using design thinking techniques. The process involves the double diamond rule for brainstorming and the outcome is a set of question and acceptance criteria for the story.

1. SHE QC A story grooming
technique
By Ranjith Tharayil

2. • Our story grooming's are not
effective
• Grooming is taking a lot of time
• Our acceptance criteria's are week
• Story grooming meetings are boring
• There are so many unknowns even
after grooming
• How to structure your 3 Amigo
discussions ?
Do you have any of
the below problems

3. SHE QC Acronym for
1
Sad
Scenarios
• Sad flow
2
Happy
Scenarios
• Happy
Flow
3
Exceptional
Scenarios
• Never
Expected
flow
4
Quality
Scenarios
• Non
Functional
Requireme
nts
5
Constraints
Scenarios
• Any
System
constraints

4. Happy scenarios
and Sad scenarios.
These are basic
scenarios identified
without much effort
if you have a
Product Owner

5. Exceptional scenarios
• scenarios we typically don’t anticipate.
• For example, “How should the system
behave in case one uses a faulty ATM
card?”
• another example “How should the system
behave if the brake controller task
crashes?”.
• Exceptional scenarios are out of the box
scenarios , which we don’t expect to
happen.
• Exceptional != Sad

6. Scenarios related
to Quality
attributes
• Nonfunctional
requirements
• like performance, reliability,
availability etc .
• e.g could be “How should
the system behave in case
the server takes more than
3ms to respond?”

7. Scenarios pertaining to
Constraints
• Architectural or infrastructure constraints
• Example let assume our systems can support 10M
translations per second in that case
• how should our system behave in case there are 10M+N where
N >=1 transitions?

8. The SHE QC ideation
Conversation
Engine
HAPPY & SAD
scenarios
Specification by example
Dev + PO +
QA + Ops
More
scenarios
Questions
PO and Arch
Input OutputScrum Master facilitates 30 to 45 min per complex story
Pre- Requisite before the meeting:
· Minimum quorum for the meeting: PO, SM, Developer(s) , QA ,Ops
· Time duration: 30 -45 min per story
· Product Owner (PO) ready with basic scenarios in the form of “Specification by example”

9. STEP 1
EXPLORE
First, 5 min Product Owner explains the story with basic
scenarios which would cover most of the happy and sad
cases . She also emphasizes on the value of the
story.(Why?)

10. STEP 2
DISCOVER
• Next 15 min discussions are focused to carve out more scenarios
that the PO might have missed out, the scenarios are written
down bucketed under different scenario types .
• Quantity over Quality

11. STEP 3
UNCOVER
• In the next 15 min, we iterate over each scenario type with an
objective to cover scenarios that we might have missed.
• We do this by focusing only on a type of scenario for a focused time
say for example exceptional scenarios for 3 min then quality scenario
and so on .
• This approach gives the team to narrow there focus and think in that
scenario dimension.
• One should keep in mind that we don’t shoot down any scenarios

12. STEP 4
CONVERGE
• The next 10 min we identify the Must Have Scenarios (MHS).
• explosion of scenarios,
• identify the right minimal set of scenarios or must have scenarios.
• The MHS are across different types and not just happy and sad
• Remove scenarios we don’t want to build
• Rest of the scenarios are grouped and pushed back to the backlog

13. 1
Explore
• 5 min
• Product Owner
explains basic
scenarios
2
Discover
• 10 min
• Discover any
missed out
scenarios
3
Uncover
• 15 min
• iterate over each
scenario type
• Focused ideation
4
Converge
• 10 min
• identify Must Have
Scenarios (MHS)
PO pulls out a story
• Identifies
HAPPY and
SAD serious
• Specification
by example
• More scenarios
• Question to
Business and
Architecture
The SHE QC ideation

14. Typical Anti-patterns
• PO is not prepared
• Team is not available (the spectrum -> PO, SM ,
Dev ,Test ,Ops)
• MHS are only happy and sad scenarios
• Lack of active participation by members
• Use the technique for simple stories
• Developing all scenarios and not carving out an
Minimal Viable Story

15. Outcomes
• Must Have Scenarios that
needs to be developed
• Better clarity, confidence and
better estimates
• A platform for structured
collaboration, DevOps enabler
• Early discovery of the unknown
• Clarification Question to PO
• Clarification Question to
Architect
• Ideal technique for continuous
grooming