Rapidly changing market conditions call for shorter software release cycles, leaving less time for longwinded specifications that often take weeks or months to write. With that in mind, where does that leave the traditional business analyst?
Traditional business analysis assumes the client knows exactly what is required, makes no changes, and that multiple workshops are guaranteed to cover everything. Right? Wrong...
Sadly, the above is often the foundation of a costly exercise for the client, with hours spent in workshops and constant document changes requiring sign-off. The bigger the project, the more complex the sign-off process - this often leads to the client not obtaining exactly what he wants and deferring changes to "phase 2, 3, 4..."!
What is Agile?
The definition of the word agile in the Oxford Dictionary is: "Characterised by quickness, lightness, and ease of movement; nimble."
Agile in software development is not dissimilar - Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organising, cross-functional teams - Wikipedia.
Step in... the Agile business analyst.
The Agile business analyst can be part of the development team, but is most commonly working alongside a product/business owner to work out high-level requirements in the form of 'user stories'. In addition to writing user stories, which I will explain shortly, they also enjoy using other skills a lot more, such as collaboration, facilitation and leadership, which makes their role far more exciting.
Agile ranks simplicity over creating complex systems.
A user story is a lightweight requirement of high-level system behaviour, often encompassing a feature that has meaning to both client and team. It is not a full specification, but it does include the requirement written in easy-to-understand English, with clear acceptance criteria. It is also a placeholder for conversation to discuss the requirement in more detail. User stories are bite-sized chunks of work and are easy for all involved to understand exactly what is required. Once delivered, the story will represent a feature of the overall system.
Agile ranks simplicity over creating complex systems. It has independence between features, so design is contained within the user story and each story is able to be tested independently, eliminating the need for complexity.
Bill Wake, XP and Scrum coach, defined the 'invest' model for requirements definition when writing user stories:
Independent
* Avoid dependencies on other stories
* Write stories to establish a foundation
* Combine stories if possible to deliver in a single iteration
Negotiable
* Stories are not a contract
* Too much detail upfront gives the impression that more discussion on the story is not necessary
* Not every story must be negotiable, as constraints may exist that prevent it
Valuable
* Each story should show value to users, clients and stakeholders
Estimable
* Enough detail should be listed to allow the team to estimate
* The team will encounter problems estimating if the story is too big, if insufficient information is provided, or if there is a lack of domain knowledge
Sized appropriately
* Each story should be small enough to be completed in a single iteration
* Stories that may be worked on in the near future should be smaller and more detailed
* Larger stories are acceptable if planned further out (epics)
Testable
* Acceptance criteria should be stated in client terms
* Tests should be automated whenever possible
* All team members should demand clear acceptance criteria
Real benefits
The business analyst now gets to think and write light specifications and facilitate discussions rather than long and lengthy documents that people don't often read or understand.
The business analyst gets to make more use of other skills such as facilitation, coaching, team-building and leadership.
The business analyst gets to deliver increments of software with the team on a regular basis and change direction if necessary - one business analyst does not need to have all the intellectual property on a project.
The client takes a lot more ownership by working with the business analyst on crafting stories and accepting delivery of software.
Costing projects becomes much easier, as business analysts can, with the team, assign development time at a story level, helping the client to decide what is really required and make sound decisions.
Transitioning from traditional to Agile business analyst is as simple as spending a few hours with an Agile coach to set you on the path: really, it's that simple!
* In the next Industry Insight, I will look at how training Scrum masters and not teams could be detrimental.
Share