Agile user stories
There was a great conversation on what agile user story is with one of customers last week. It's very important to be on the same page talking about user stories with a customer. A good user story gives enough information of customer's expectations to start implementing or estimating a feature. It is a manifest of an upfront conversation with a customer.
Story sections
Having that in mind let's see what a good user story should contain:
- user role (who)
- actions to perform (what)
- result achieved (why)
User role is a role of a person who will interact with a product. Say sales manager that interacts with the product will be able to sell items from the warehouse. Business owner will be able to see sales statistics and so on.
Actions to perform are actions to be performed by user to achieve expectations.
For instance: create new purchase order, edit existing line item.
Result achieved matches customer's expectations most of time. So it's what we are willing to reach.
Sample user story:
As a designer I want to be able to send arts to a customer so that a customer could examine if the job was done right and within a time frame.
Additional requirements
Based on customer's expectations we can add any additional comments or notes to the user story. We can refer to external documents from a user story as well. There are no restrictions on what should be covered in a story. People don't like some boring reading though. So I'm up to stay sharp and short writing ones.
Accomplishments
It's really important to have an acceptance criteria when you start estimation process. Such a criteria gives you a solid ground of what exactly should be delivered as an output. It can be a starting point to perform QA as well.
Tasks ordering
When we are done with user stories definition there is another thing to mention. User stories can be pulled from stack in any order. Some of stories are of higher value for a business and some are of low value. That's why it's a good practice to order user stories according to business value. Order of tasks defined by business allows to deliver the most critical tasks first.
Notes
We were able to reduce the amount of bugs created by our QA guys by 17% having development team involved in initial user stories discussion. We've pushed hard to make acceptance tests more precise as well.
User stories in agile methodology
All in all development in agile methodology starts with user stories which should provide minimal amount of information required. It's up to you what to include in a user story and what to exclude. I just wanted to provide you with a notion on what a good story should contain to make communication among parties proficient.
PS
It is really useful to have design and UX development done before actual code implementation phase.
For further reading
http://www.boost.co.nz/blog/agile/acceptance-criteria/
http://xprogramming.com/articles/expcardconversationconfirmation/
http://www.scrumalliance.org/articles/367-its-ordered--not-prioritized
There was a great conversation on what agile user story is with one of customers last week. It's very important to be on the same page talking about user stories with a customer. A good user story gives enough information of customer's expectations to start implementing or estimating a feature. It is a manifest of an upfront conversation with a customer.
Story sections
Having that in mind let's see what a good user story should contain:
- user role (who)- actions to perform (what)
- result achieved (why)
User role is a role of a person who will interact with a product. Say sales manager that interacts with the product will be able to sell items from the warehouse. Business owner will be able to see sales statistics and so on.
Actions to perform are actions to be performed by user to achieve expectations.
For instance: create new purchase order, edit existing line item.
Result achieved matches customer's expectations most of time. So it's what we are willing to reach.
Sample user story:
As a designer I want to be able to send arts to a customer so that a customer could examine if the job was done right and within a time frame.
Additional requirements
Based on customer's expectations we can add any additional comments or notes to the user story. We can refer to external documents from a user story as well. There are no restrictions on what should be covered in a story. People don't like some boring reading though. So I'm up to stay sharp and short writing ones.
Accomplishments
It's really important to have an acceptance criteria when you start estimation process. Such a criteria gives you a solid ground of what exactly should be delivered as an output. It can be a starting point to perform QA as well.
Tasks ordering
When we are done with user stories definition there is another thing to mention. User stories can be pulled from stack in any order. Some of stories are of higher value for a business and some are of low value. That's why it's a good practice to order user stories according to business value. Order of tasks defined by business allows to deliver the most critical tasks first.
Notes
We were able to reduce the amount of bugs created by our QA guys by 17% having development team involved in initial user stories discussion. We've pushed hard to make acceptance tests more precise as well.
User stories in agile methodology
All in all development in agile methodology starts with user stories which should provide minimal amount of information required. It's up to you what to include in a user story and what to exclude. I just wanted to provide you with a notion on what a good story should contain to make communication among parties proficient.
PS
It is really useful to have design and UX development done before actual code implementation phase.
For further reading
http://www.boost.co.nz/blog/agile/acceptance-criteria/
http://xprogramming.com/articles/expcardconversationconfirmation/
http://www.scrumalliance.org/articles/367-its-ordered--not-prioritized
