Skip to main content

The Focused Analyst

Have you ever:

  • Started what you thought was a simple analysis task, only to find yourself unravelling a web of mystery?
  • Revised work that was completed early because things changed in the interim?
  • Suffered from Analysis Paralysis – continually re-analysed a situation instead of moving forward?

If you answered yes to the above, you’re probably a business analyst. So what steps can you take to promote the delivery of analysis that is relevant, has a clear purpose, and is available at the point-of-need? Perhaps there are some lessons to be learnt from agile delivery.

A distinction is often made between agile and “other” business analysis techniques. However, many of the techniques that are used to organise and prioritise work in agile projects can be employed more generally. This article summarises agile principles and techniques that can be used to plan work, manage stakeholder expectations, and focus on the delivery of real value – regardless of the delivery environment… agile, waterfall, other or undefined.

1. Definition of Done

The Definition of Done is a list of criteria which must be met before a work item (usually a user story) is considered “done.” In agile delivery, the criteria are agreed by the agile team prior to commencing work. Once a work item meets the criteria, it is considered done – and “done” means done!

The idea of “done” can be expanded to work performed outside of agile projects. Agreeing a Definition of Done with relevant stakeholders is a good way to set and manage expectations and identify priorities, prior to commencing work. This can promote more focussed analysis by providing a clear end-point, reducing the risk of both over-analysis and scope creep.

2. Relative Estimation

In agile delivery, effort is a relative measure. Effort is measured by comparing tasks and assigning points. Each task is assigned a single point value (usually a number from the Fibonacci sequence) individually by each agile team member to denote how much effort they believe the task requires. Tasks that are considered more onerous compared to others are assigned a higher number of points, while tasks that are considered comparable are assigned the same number of points.  Where individual point values differ, the team discuss the reasons why to reach a consensus value. As tasks are completed over the course of an initiative, the actual effort-to-point ratio becomes apparent leading to more accurate estimates.

Relative estimation is useful as it is generally easier for individuals to predict whether a task will take more, less, or the same effort compared to another, as opposed to accurately measuring the time and resources required to complete a single task without comparison. Receiving estimates from multiple stakeholders/individuals is likely to result in more accurate estimates as additional variables may be considered. While it may take time to estimate enough tasks to accurately understand how points translate into actual effort, the result should ultimately be better, more reliable estimates for a range of work activities.


Advertisement

3. Just Enough, Just In-Time

As a rule, analysis and design activities in agile are performed on a just enough, just in time basis – just enough to not waste time conducting analysis and/or completing documentation that doesn’t add value, and just in-time to ensure analysis is current and available at the point-of-need.

Analysis is rarely done for its own sake – it is an input for further analysis, design and/or decision-making activities. Ideally, analysis work should be completed as-and-when it is required to ensure it is relevant. Focusing on why and when analysis is required provides a foundation for delivering just enough value-adding analysis, just in time.

4. Regular Reflection

In agile delivery, a retrospective is held at the end of every iteration. Agile team members reflect on the previous iteration as a way of learning lessons and implementing changes to improve the delivery process. Open and honest feedback is encouraged, and elicitation techniques such as Stop-Start-Keep, Affinity Mapping and Brainstorming are used to promote full participation. Because reflection happens regularly, the changes required to address concerns are usually small and/or incremental, making them easier for the team to implement and monitor.

While most project methodologies promote the logging and reviewing of lessons at fixed points in time, this often happens too late to be applied to current initiatives. The regular reflection and change promoted in agile has the benefit of allowing learnings to be applied early when they may be of most benefit to the initiative. Including regular retrospectives in normal work practices can be a good way of promoting and implementing continuous improvement.

5. Focus on Progress – Not Perfection

Agile focuses on making progress – not obtaining perfection. Agile delivery sets up a system that can respond to new information through iterative feedback and refinement. Work items are constantly reviewed and revised as new information comes to light. As work items are completed, they are made available to stakeholders who are encouraged to provide feedback. It is generally accepted that initial versions will not be good enough, but that open and regular reviews will provide the information required to make them acceptable.

There are some simple steps for promoting the principle of progress over perfection in everyday business analysis. Set expectations early – never promise perfection. Engage stakeholders regularly – multiple short, sharp engagements can be more productive compared to longer one-off meetings. Focus on analysing what is important. Produce deliverables in a format that supports regular updating. Where possible, create “living documents” that are updated as-and-when information becomes available. Don’t be afraid to present work that may be incomplete or incorrect – showing the wrong answer can be an effective route to right answer.

Conclusion

Many of the principles and techniques associated with agile delivery can be employed in business analysis more generally. Pigeonholing techniques into “agile” and “non-agile” may mean suitable analysis techniques are overlooked.  The principles and techniques that help agile teams organise and focus on delivering can assist in the delivery of timely, value-added analysis – regardless of the delivery approach.

Resources:

The Agile Samurai: How Agile Masters Delivery Great Software, Rasmusson, Jonathon, 2010.

Agile Alliance – Definition of Done, https://www.agilealliance.org/glossary/definition-of-done, accessed October 2020.


Anna Rajander

Anna Rajander is a Certified Business Analyst Professional with almost 20 years’ experience in both business analyst and project management roles.