Agile is growing in popularity and is a hot topic in business analysis circles. In fact at the IIBA Business Analysis conference in London this year Agile was very prominent.
This article sets out some of the attributes that make the agile methodology successful but also explains what lessons can be learnt and applied for the business analyst regardless of the methodology. When providing Agile examples, the approach called SCRUM will be used as it is the most popular agile approach.
Refer to the article How to identify the most appropriate methodology for a project for an explanation of the types of methodologies and when one might be more suitable over the other.
- Greater communication / collaboration with customer / end users
In agile the customer/end user are key members of the team and are empowered to make design decisions. There are regular meetings where they are kept up to date and asked to contribute.
Regardless of methodology greater collaboration and involvement of the customer will ensure issues are resolved faster and ensure the solution being developed fits with their expectations and enables buy in. The business analyst should aim to build up a good rapport with the customer so they can be consulted regularly and a relationship built where a phone call or impromptu visit at their desk is well received. It shouldn’t always be necessary to arrange a meeting.
- Involvement sooner from developer and testers
In agile developers and testers are involved at the same time allowing their input and direct communication with the customer to increase their understanding at the early stages with what is required. This helps make sure they understand the requirements.
Opportunities to involve these stakeholders sooner will therefore be advantageous. The business analyst should therefore aim to build up the same relationship as described for the customer.
- Use of prototypes / working versions so can see results sooner
In agile prototyping and working versions of the software are provided as part of solution design / development process. This enables customers to see results sooner and to incorporate change faster.
Prototyping can be incorporated regardless of methodology and is a great tool for ensuring understanding and consensus. Prototyping doesn’t have to be high fidelity such as the use of software, the business analyst can use low fidelity prototyping techniques using pen and paper. See article The benefits of using Storyboards to gather requirements for more information on this and how to apply it.
- Improved prioritisation of requirements
In agile work has to be broken down and prioritised. This is where there is a focus on a smaller subset of requirements to deliver output in something like a 4 week time period. This forces prioritisation as decisions must be made on what to deliver first.
One of challenges for a business analyst is the prioritisation of requirements. It can be common for the customer to give every requirement a rating of must have because of the fear of not getting it if rated any lower. In turn this isn’t helped if the IT department has a reputation for automatically discounting any requirements lower than a must have.
In agile there is more confidence the requirements will be delivered as results are seen sooner and divided into iterations known as sprints. These sprints are planned and the requirements can be moved around to accommodate the sprints according to priority.
The business analyst must therefore be able to challenge the business for prioritising requirements giving them confidence that a lower rating doesn’t automatically discount them and hold IT stakeholders to account for delivering the requirement. Techniques which would need good rapport with the customer could involve only allowing a certain percentage of must have requirements or ranking the requirements in priority order. Estimation techniques such as described in the article Using a use case model for estimating and planning will also help give confidence of how and when requirements can be delivered based on size and complexity.
- Responding to change
In agile re-work can be carried out as the customer understands more about what they are getting and as priorities change. Work is organised in something like 4-6 week sprints making it easier for the customer to re-prioritise what goes into a sprint as more is understood about its size and complexity.
In methodologies such as waterfall change is managed through change requests. It is important to ensure that a change request process is in place and an impact assessment is carried out promptly to understand how easily a change can be made. It is also important to make sure that requirements documented are at the right level and are not gone into detail too quickly. See article The hierarchy of requirements and how it impacts requirements gathering? for an explanation of the hierarchy. The impact of mixing this up is that change will need to be incorporated quicker than required. Another factor in making change easier is to make use of diagrams over large reams of text. This will make changing the documentation easier as well as making it easier to pinpoint where changes are required and keeping up to date. The article The Importance of Diagrams in Business Analysis provides more explanation on why diagrams are so useful and the different types that you may find useful.
Thoughts? Questions? Please share in the comments.
