Until User Stories came into existence, requirements, in my opinion hardly spoke about the person who needs it or why the person needs it. It was impersonal.
The good thing about Agile User Story is that it tells who wants it - is it an Admin who needs it? is it a data operator who needs it? And it also tells why it is required. That is the key - The 'why' gives the developer or a tester the 'value' or the importance of doing that story.
Scrum is all about delivering value. The user story should talk about it. How else can the person developing or testing it will get a sense of importance of the work he/she is doing?
User story should tell us the below details:
- Who wants? The Persona
- What do they want? The task to be done
- Why they want? The value
- And then how do I test and Accept that its done, once the story is completed?
That is all that is required in a Story!
Eg:
As a shopper, I want to be able to search for any product and also be able to apply filters, so that I can find the specific items that I am looking for.
Acceptance Criteria:
1. Search button and search text box should be visible clearly.
2. User should be able to enter the data in search box
3. Filters should include options for Prize, Size, Color
4. On clicking the apply filter, search results should change appropriately
Now a good Story should also follow the INVEST principle.
I - Independent - It can be independently shipped to Production.
N - Negotiable - A story is not a signed contract. Its subjected to change. It should be flexible. In the above example, if we need to add another filter, we can/should be able to do it.
V - Valuable - It should have a purpose
E - Estimable - We should be able to give an estimate
S - Simple
T - Testable - Able to test and accept its completion
No comments:
Post a Comment