Clear user requirements using agile user stories and automated testing

It is vital to have clear user requirements. This can be achieved by using agile user stories. Lately one of the biggest problems we experience in the agile space is the lack of clearly defined requirements.  Lack of clear defined non agile requirements results in a lot of problems during the development cycle.  The following is just some of the key observations around this:

[list_icon color=”blue” type=”icon_arrow”]

  • Lots of rework is identified during Scrum sprint reviews from the business
  • User stories are often only really completed after 3 agile scrum sprints as rework is identified in 2 or 3 agile scrum sprint reviews.
  • This means that the business is paying 2 – 3 times for delivery of a user story.
  • A typical non agile requirement specification goes into the agile scrum sprint. By the time the scrum sprint ends the non agile requirement specification is no longer valid as changes have been made to it due to lack of detail in the original agile requirements and no one bothered to update it

[/list_icon]

So to overcome issues during requirement definition we use a more agile way of documenting business requirements using agile user stories.

So what is so great about this approach of documenting user stories? Well there are a few benefits of agile user stories that we can highlight here:

[list_icon color=”blue” type=”icon_arrow”]

  • It clearly defines what is required for agile user stories
  • It provides test data as part of agile user stories
  • It forms acceptance criteria for agile user stories that can be used during user acceptance testing (uat)
  • It can be used during automated agile testing
  • When changes are required we update this within agile user stories resulting in user stories being living requirement documents, unlike non agile requirement specifications
  • If you are automating using user stories then it saves developers, testers and the business execution of all the repetitive tasks during quality assurance (qa) or user acceptance testing (uat)
  • It assists to bridge the gap between IT and business and it serves the need of both audiences. Wow!
  • We can use it to keep our codebase clean of unwanted code, implemented but never materialized

[/list_icon]

So what type of user stories do we get?

[list_icon color=”blue” type=”icon_arrow”]

  • Functional user stories, specifying functionality and used to test if an application is doing what it is suppose to do
  • Characterisation tests, aimed at discovering the behavior of old legacy code
  • UI user stories, aimed at simulating the interactions of users with a user interface, thus the process flow of the user throughout the ui

[/list_icon]

Enhanced by Zemanta

Interesting Infoware Studios Bookmarks

0
  Related Posts