Author: Lorraine Pauls Longhurst Published: LPLSC Blog Date: 12 March 2009
What happens when Scrum projects do not have clear user stories? What if the Business Analyst (or Product Owner) just provides functional requirements?
The best way to communicate requirements in a way that will make the developers more productive is for the Product Owner (or Business Analyst) to write requirements as user stories. They should be worded in the following way: ‘As a’ user ‘I want to’ do the following ‘so that’ the following benefit can be met. The only way to do this is to communicate with the user frequently which is a very important part of Agile Development.
The team I started coaching last year had a Product Owner who was able to speak on behalf of the business and make decisions. That is the most important role of the Product Owner right?
Not necessarily. Just because they have the subject matter expertise and decision making capabilities, does not mean they can clearly communicate the requirements in a way that will make the developers/testers as productive as possible.
As a Scrum Coach, I came in to an already well underway Waterfall project where the Product Owner and Architect had spent many many months writing a very detailed specification for a custom (bespoke) software development project. A lot of up-front analysis was done and requirements were outlined either as technical or functional features for the developers to code, with no explanation of who needed it and why.
The Architect and Product Owner told the developers exactly what features should be added. This not only impacted the morale of the team, since the developers were not able to be creative, but because the team did not know why they were developing a feature, they often built features that did not meet the users' needs.
Example:
A product backlog item says 'Administration Tool' and the functional requirement outlines a list of business rules that must be followed when the user edits various data in the database through this tool.
The developer did as he was told and developed software to do this without understanding who the user was and why they needed this. The solution included a GUI front-end which updated the data in the database based on these rules.
The best way to communicate requirements in a way that will make the developers more productive is for the Product Owner (or Business Analyst) to write requirements as user stories. They should be worded in the following way: ‘As a’ user ‘I want to’ do the following ‘so that’ the following benefit can be met. The only way to do this is to communicate with the user frequently which is a very important part of Agile Development.
In the example above, the requirement was re-written as follows:
'As a System Administrator, I want to be able to add new data import systems without re-deploying the application, so that the system can support multiple new import systems within the next release'.
We quickly realised that the solution the developer had put in place did not solve this particular problem for the user. The Product Owner had thought of every rule (i.e. every piece of data that may need to be altered) but he had forgot the most important use. A different (and much simpler) solution needed to be developed.
By providing a requirement as a user story, it enabled the developer to consider different possible technical (and functional) solutions to solve a problem. They can then choose the best option that will fit within the time-boxed sprint. Future enhancements to that solution can be accomplished in future sprints depending on the priority of those enhancements for the user.
