Quick Ideas for BA's in improving User stories for iterative delivery
Most of the teams/ business representatives consider user stories as simple requirements and write in a casual manner. As said by “Gojko Adzic and David Evans”, user stories imply a different model: requirements by collaboration. In place of documents hand-over, frequent discussions, meetings with all stake holders, technical-business knowledge inputs will pave way for product ideas and faster build during short delivery phases. · Try story telling instead of writing down details.
· Use physical cards (like Kanban or 3 C's- Cards, Conversations-Confirmation), management tools etc. for initial engagement.
· Engage stakeholders and delivery team members in a discussion, look at a story from different perspectives and explore options.
That’s the way to unlock the real benefits of working with user stories.
Benefits:
I. Playback sessions help business stake holders, team members and delivery management to explain what their requirements, needs and views are.
II. Any misunderstandings and disagreements are nullified preventing knowledge gaps. Explaining (discussing) face-to-face or on video conferences elevates common vision of the business requirement.
III. Faster analysis: With the entire team engaging in discussion, functional gaps, and unclear requirements gets addressed.
I found PEGA platform is a wonderful tool which allows to capture requirements, specifications in real-time (DCO). This allows easy access to all global stakeholders, review, comment, share feedback and approve.
Okay, so what is the standard user story format?
There are tons of suggestions in Google if you search for a perfect format. Firstly, what is a user story?
“It is an activity an actor (system, persons etc.) should be able to perform”.
e.g., As a product owner, I would like the system to notify me once the order is dispatched.
As an actor(s)= Who are the group of individually that work is being done for.
I want= What work is being done (accomplished to meet the needs). This I want covers function.
So that= Why the work is being done (to address customer needs). This So that covers business reason.
There are three reasons why you shouldn’t worry with a format, “as long as the key elements are there”.
A story is ideally a piece of information and conversation that carries elements: “actor, function and business reason”.
Writing code is a long artifact, whereas user stories are the outcomes of the discussion/ meetings/ play backs sessions. Hence, a standard format doesn’t applicable. A simple and great user story structure for every Business analyst to kick start: “As a user (actor), I want ……”
Benefits:
I. Let go away template. Instead, try with different formats to elicit creativity, discussion and participation from stakeholders.
II. Focus on problem statement first rather than Software implementation.
The key to a good User Story:
Bill Wake relates the characteristics of a good user story with an acronym “INVEST”.
I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable
Benefits:
I. Capturing behavior changes (the WHY?) makes story measurable and elicits more solution ideas.
II. Describing these changes, allow teams to assess if the user story is been delivered as per the business requirement.
III. Once a change is identified, ask “how much”? This is to measure and asses the change the solution ideas triggered.
Acceptance Criteria:
It is nothing but “how the user story is verified”. When a user story is initially put forth, the nature of what should be changed in the system is a subject of debate, given the choice between several designs?
Once the best solution design is agreed upon, the user story should be clearly written on the current system functionality VS post implementation. This helps in understanding the scope of work, user story implementation to gain acceptance.
Should use sentences:
"Whereas currently…."
"Instead of…"
"I want + action verb" == I want to use…
Lastly, the user story creation needs:
1. Thorough understanding of the business problem statement.
2. Don’t bother on what is the standard user story format, instead ensure the 3 key elements are covered.
3. INVEST in good user stories
4. Document Acceptance criteria
#Agile #scrumteams #abcsofagilescrumframework #authorsblog #agileprojectmanagement #gsubashcosmopolitan #businessanalysislifecycleandITbusinessanalystrole #amazonebook