Gathering agile requirements for our service 15 Aug 09

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

In this post we will talk briefly about how we gathered our requirements for the Outfarm Service. We are using an agile development approach and will be using userstories as the basis for our requirements. A userstory is a software requirement described in one or two sentences using everyday or business language of the user. This enables non-technical business people to formulate the requirements using their own language, because they will the use the new system afterwards. And in case you wondered, yes they have to come up with the requirements, not an analyst who is already removed from their day to day problems.

There are many ways of getting the user to come up with the requirements: interviews, questionnaires and workshops to name a few. Because we build a service platform that we would use ourselves, we chose to organize a workshop. Many of the steps we used are coming from Mike Cohn’s excellent book “User Stories applied for agile software development”.

The workshop has three distinct modules:

• Role-Modeling
• Userstory gathering
• Acceptance test gathering

Role-Modeling: Every application will be used in different ways by users in different roles. The idea of the workshop is to tease out those user roles that will then be used as the basis for the userstories. We started with a brainstorming session ending up with many overlaping user groups. Next step was to consolidate and condese the overlaping roles to a few roles that define these strongly overlapping user groups. And the last act was to think about attributes such as: how often are they using the software, level of domain expertise, general goal for using the software, proficiency with the software developed and general proficiency with computers and internet. We defined our own roles first and then went on to define other roles we thought would be using this software including the person who makes the buy decision for our service.

Userstory gathering: There are many ways to gather user stories: User interviews, Questionnaires, Observations, Story Writing Workshops and working with user proxies such as product manager, sales/markting or business analyst. We used a combination of user interviews and story writing workshop to come up with a simple conceptual prototype on paper and resulting userstories. Our software is a web application so we used high level pages (no page details included) as the basis for the prototype and started with an empty page. For each role we then defined what actions they could take from here and these actions would become a userstory and add pages to the prototype from which we would look for more possible actions and add more pages. While walking through the prototype one role at a time, we asked the following questions:

• What would this role most likely want to do next?
• What mistakes could he make from here?
• What could confuse the user at this point
• What additional information could the user need?

Throughout the workshop we kept in mind to keep the discussion at a high level and to come up with as many stories as possible. And throw away the simple prototype because all the information should now be captured in the usesrstories and the prototype will only create confusion when all of a sudden someone revisits it after a month.

Acceptance test gathering: The last post is already concerned with testing, therefore we only want to add a few more things:

• Write tests before development starts as they give the developer boundary conditions during developemnet and for effort estimation
• The end user/customer needs to specify the acceptance tests with the help of the developers
• Testing is part of the process and happens throughout development and not just at the end
• As long as tests add value, they should be added. Additional tests can and should be written throughout the lifetime of the project
• Automate acceptance testing using frameworks because manual testing is error prone and mind numbing to the testers
• Acceptance tests should cover different types of testing (Functional testing, User interface testing, Usability testing, Load testing)