INVEST on User Story- Definition of agile user story
What is User Story?
Agile methods typically tend to be “lighter weight” specifications and requirements are written as user stories.
A user story is a high level description of system behavior. It is not a full specification of the requirement but a placeholder for conversation about the requirement. The user story will be fully specified as it is brought into an iteration or development cycle.
Once delivered, a user story represents a fully functional (although possibly incomplete) slice of the overall system. Several in the agile community have suggested guidelines to help us determine what makes a good user story.
INVEST Model:
Bill Wake author of “Composing User Stories” defined the INVEST model for requirements definition. INVEST is the mnemonic to remember the characteristics of a good quality user story.
Independent
• Avoid dependencies with other stories
• Write stories to establish foundation
• Combine stories if possible to deliver in a single iteration
Negotiable
• Stories are not a contract
• Too much detail up front gives the impression that more discussion on the story is not necessary
• Not every story must be negotiable, constraints may exist that prevent it
Valuable
• Each story should show value to the Users, Customers, and Stakeholders
Estimable
• Enough detail should be listed to allow the team to estimate
• The team will encounter problems estimating if the story is too big, if insufficient information is provided, or if there is a lack of domain knowledge
Sized Appropriately
• Each story should be small enough to be completed in a single iteration
• Stories that may be worked on in the near future should be smaller and more detailed
• Larger stories are acceptable if planned further out (Epics)
Testable
• Acceptance criteria should be stated in customer terms
• Tests should be automated whenever possible
• All team members should demand clear acceptance criteria
Conclusion:
Success in today’s economy requires us to respond quickly to changing market conditions and business needs. Traditional product delivery methodologies cannot deliver fast enough in highly uncertain project domains. Agile methodology allow teams to meet the changing demands of the customers while creating environments where team members want to work.
The Business Analyst can play a key role on an agile team. To be successful, BA first need to shift their traditional requirements thinking. Additionally, BA need to consider learning new skills for writing requirements and new techniques for managing them. Success will depend largely on how well BA adapt to these new ways of working with requirements, setting up teams, and using group collaboration.
Depending on the level of formality required by an organization, BA will want to consider using either use cases or user stories.
No comments:
Post a Comment