Moving Gradually to Agile Development and Scrum

Stage 4: Ensure requirements are user stories that incorporate real feedback

Now that the team is developing high quality software and productivity is starting to improve it’s extremely important that you ensure that what they are building is exactly what the user wants.

In traditional projects, a lot of up-front analysis is done and requirements may be outlined either as technical or functional features for the developers to code, with no explanation of who needs it and why. Because of this, the team may still be building software that does not meet the user needs due to misinterpretation of the user (by the Business Analyst) or misinterpretation of the Business Analyst (by the Developer).

At this stage, it is important that the Business Analyst steps back and examines the high priority functional requirements scheduled for the next iteration to ensure that they fully understand the requirement and are communicating it clearly.

The best way to minimize misinterpretation is 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 Business Analyst must make it clear what is expected at the end of a sprint – also referred to as ‘the definition of done’. To communicate this clearly acceptance tests should be written.

To ensure that the team has actually developed what the user wants, at the end of each sprint, demonstrate the solution and get feedback from the user! For software that is already in production, ensure there are frequent releases so that real user feedback can be incorporated. Note that the best way to enable your team to release software frequently is to introduce automated regression testing.

Scrum features introduced at this stage

Business Analysts must learn to write requirements in a new way and the business must agree to minimal documentation and sign-off. This is only possible if you have someone responsible for the product ownership that the business trusts.

The best way to demonstrate that limited documentation still works is to demonstrate the solution to the users regularly and incorporate their feedback – this is a key feature of Scrum. Ideally, the team has been producing working software at the end of every sprint, but if they haven’t been, now is the time to enforce this.

Issues overcome at this stage

It can be difficult to get organizational buy-in on limited documentation. Many large organizations are resistant to this type of change due to lack of trust in the team.

Another obstacle to overcome is the re-definition of team members’ roles. I’ve worked with teams who had an architect telling all the developers exactly what technical feature they should add. This not only impacts the morale of the team, since they are 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.

Benefits gained at this stage

The benefit gained at this final stage is that the software developed better meets the business needs. Expectations are appropriately set with the users and the software meets those expectations.

Conclusion

If your organization is having troubles introducing an Agile methodology on a custom software development project, try introducing the above stages gradually. By introducing only one stage, you can still gain the most important benefits of Scrum – the ability to re-focus based on changing priorities. Once your team has overcome the issues associated with that stage, you can move onto further stages and gain added benefits with each issue you work through.

In my experience, there are a large number of organizations that are adverse to change – especially large corporations and government organizations. In these types of organizational cultures, it is best to deal with one obstacle/issue at a time rather than getting overwhelmed with all issues at once.

I recommend that you first ensure the business is taking ownership and making decisions. I think it is best to focus on overcoming this obstacle first before moving onto the second stage.

Once a Product Owner has taken control of a prioritized product backlog and the team is working on only the top-priority requirements, it is then time to explain the benefits of Agile to the business. Once they have bought-in to Agile and are given more control over the project, it is then time to focus on improving software quality.

Improving team collaboration will ensure that developers, testers and business analysts are all working towards the same objectives in each sprint will enable you to reach the goal of zero defects at the end of each release.

The final goal is better met user expectations which I think is only possible through the introduction of user stories, acceptance tests and regular demonstrations with users. Getting the business to agree to new processes around documentation can be difficult as it requires that trust in the team is established – which again is difficult to do until the initial obstacles have been overcome.

About the Author
Lorraine Pauls Longhurst is a Certified Project Manager with expertise in the use of Agile software development methodology (SCRUM / ADM) with LPL Software Consulting (www.lplconsulting.com.au) based in Sydney Australia.