Role of the Business Analyst in Agile

The purpose of this article is to explain the role of the business analyst in an agile project.

Business analysis starts way before implementing the agile methodology process.

Before using it to design and develop a IT system there needs to be an understanding of the following business analysis tasks:

• The problems that need resolving
• The opportunities and success criteria
• The business processes
• The scope
• The business goals and stakeholder requirements
• The stakeholders to involve
• Estimation of the size and complexity of each of the requirements (or velocity in scrum terms)
• An initial plan of the order and prioritisation
• Traceability – the stakeholder requirements are aligned to the business goals and solve the problems identified
• Common understanding and consensus between stakeholders of the problems identified, success criteria, business goals and stakeholder requirements
• Solution options available and agreement of system boundaries

Some of these may evolve but there needs to be something other than a blank piece of paper before design can start.  Without these it would be impossible to know who to engage, what technical skills were required, the IT architecture, what problem needed to be solved or what work needed to start first.

Throughout agile as with other methodologies the business analyst is responsible for making sure the design and development match back to the business goals, stakeholder requirements and in line with the success criteria as it develops further.  They are also responsible for ensuring common consensus between the stakeholders.  This is even more prominent in agile because scope isn’t fixed so there is more change to manage as re-planning and re-prioritisation will be required to respond to change through a number of different iterations.  Communication and collaboration will be a key skill for the business analyst.

Not all agile methodologies define a business analyst role.  This does not mean no business analyst involvement.

In practice taking scrum as an example the business analyst may take the role of scrum master, product owner or be a main conduit between a mixture of roles.

A scrum master will be a facilitator to ensure:

• All stakeholders are involved
• To track work progress
• To identify and discuss risks and issues
• Manage changes required to ensure tangible outputs can still be provided at the end of each iteration

A product owner will:

• Define the solution requirements
• Prioritise according to the greatest need of the business
• Review and provide feedback on the solution throughout each iteration progress
• Provide design authority decisions

A mixture of roles may mean that the business analyst might:

• Act as a product owner or be a second voice to the product owner when they are not available but ensure they are kept up to speed and have enough understanding to be able to make decisions.  The product owner from the business then may have more involvement with reviewing the outputs further into the iteration.
• Work with the developers and product owners to document user stories and define the acceptance criteria.
• Work with the developers to communicate the goals, requirements and agree first draft of prototype on paper before communicating it back to the business to ensure common starting point.
• Work with developers and product owners to resolve issues as they arise
• To help track requirements against priorities, identify gaps and ensure business value focus.
• Be the first point of contact with developers to review progress, outputs and conduct acceptance tests.
• To ensure some level of documentation to:
  • Enable understanding especially business rules that might not be obvious from looking at a working prototype.
  • Enable support activities post implementation.
  • Enable re-use once the project is implemented.

The important thing to note is that all of the above is business analysis but this doesn’t necessarily mean that the person doing the tasks has the job title of a business analyst.  Business analysis is very much prevalent in all of the project methodologies.

Thoughts? Questions? Please share in the comments.

 

If you have found this article useful then you might like my book – The Business Analysis Handbook – Techniques and Questions for better Business Outcomes.  The book is available from www.koganpage.com and all major print and e-book retailers.