Seven years ago I was involved in an open debate at an IIBA meet up on the role of Business Analysts within an Agile environment. At the time my opponent contested that Business Analysts were defunct under Agile and were no longer required. I debated that they were still needed but that their role changed somewhat.
My main argument was that they were no longer the provider of lengthy requirements documents written in advance with little to no collaboration in the team. This didn’t mean that Business Analysts were no longer required to write any form of documentation, just the amount of documentation, the collaboration involved to reach a common understanding and the timing of when the documentation is done changed. With this reduced amount of time directly spent writing ‘War and Peace’ requirements they would instead use their time in a new skill set – as facilitators. I saw the role of the Business Analyst as being very compatible with the Scrum Master role, where the Business Analyst could encourage an environment of collaboration and ensure that the ‘promise for a conversation’ occurred. Business Analysts would still need to have skills drilling into the root cause of problems, to understand and analyse and question the business process, but in a good Agile team everyone would also have this skill.
Time has moved on and most of what I predicted for the Business Analyst role has come to pass within Agile environments. But I believe that it is time to make a new prediction.
We have come a long way towards mastering the art of building the product right, our next journey is to build the right product. After all, according to Lean principles, the biggest waste is the waste of overproduction and this can take the form of producing an unneeded or incorrectly targeted product.
Thus, in today’s ever shifting environment, I see the role of the Business Analyst as that of being at the heart of data. I see the role transforming to focus more on data analytics and the understanding of data associated with the product. Some may say that this is the role of the product owner, to which I probably wouldn’t disagree with and as such I see the Product Owner and the Business Analyst roles merging even closer together but with an incredibly strong focus on data.
So what is all the data that is being analysed about? Four things:
- Are we improving the number of customers seeking our product?
- Are we retaining our existing customers?
- Are customers getting value out of our product?
- Is our product revenue model generating net profit?
If the answer is yes to the above questions, founded soundly on data then your product is in a great place. If you cannot answer these questions then you really should start working on it (before you go out of business). For those of you familiar with the Lean Startup model then the above discussion should be something very familiar to you, for I believe the Business Analyst role should be centered around enabling the data gathering to support a Lean Startup approach.
You don’t have to be a start up to gather this data. You don’t have to measure once every three months. You can start measuring your existing product and incrementally improving on the four questions right now and everyday from this point onwards. Armed with this data you can know whether a change you made today will make a difference to your business tomorrow.
Maybe the role shouldn’t be called “Business Analyst” anymore . Maybe we should start to create “Product Analyst” roles instead?
Agile Forest 
Good article. As a company we integrated IIBA business analysis into our agile process and the results are outstanding. As you discuss in the article, the role of the business analyst is now different than the past. In our agile environment it is the business analyst that works with the product owner to identify solution scope and stakeholder requirements before the scrum starts. The identification of requirements early on helps guide the product owner and team during the scrum and helps to estimate costs for parallel high level solution components that are later planned and executed during sprints.
What is the right level of business analysis that is needed before starting a scrum? The answer is “just enough”; there is no right answer. Teams must examine each engagement for stakeholder and technical complexities, in addition to the number of stakeholders and domains.
In the end the answer is “yes” there is still a role for business analyst in the agile community, but the role has changed.
Renee, I wonder what is the role of a good old product manager in your model?
Business analyst as well as product owner have been and are supporting roles for product management, which is ultimately responsible for market understanding and profitability of the product over it’s lifetime. Lean startup doesn’t really discuss the role of product manager because in a startup there is usually only one product to be managed and the founders have their full attention on it.
Product owner role comes originates from scrum world, which was developed for project business. Again, no real need to understand the market if there is only one customer and a single project.
But in every successful mature company starting from Google the one responsible for answering the four questions you listed above is the product manager, or isn’t it?
Hi Harri,
It really depends on the organisation and how they have set themselves up. In smaller or more Agile organisations I wouldn’t see a difference at all. In larger organisations or those still on their Agile journey the role may be separated where the Product Analyst is a competent user of excel, and data gathering/analytics tools. I would hope over time the roles merge together.
The Lean Startup you are referring to is the one where it is a true startup. Lean Startup principles are equally applicable on an already existing product in which case a Product Owner would normally exist. Even in a true startup the Founders are acting as the Product Owners (whether they are conscious of it or not).
I would say that in every successful Agile company the one accountable for answering the four questions is the Product Owner. The whole team should also be responsible for answering it.
Product Owner vs Product Manager – I don’t really mind what it is called, how do you see the role different? I like Product Owner better because development of a Product can be done through empowered teams or through directive leadership.
In the 1970s and 1980s, IT projects sought to automate repetitive tasks and convert records to electronic data for storage. Systems analysts documented manual paper processes, identified new business requirements, and automated the processes using computerized systems. They saved businesses the cost of some staff and improved customer service with fast access to electronic information. In the late 1980s and 1990s, companies evolved their IT systems in an attempt at more savings or better service. IT projects from this era failed over and over, either being unable to deliver or delivering without improving the business as projects lost their focus while receiving conflicting demands from various business departments. The development of systems with unclear objectives, unmanaged expectations and unrealistic business cases led to the failure. Sometimes systems were developed only to follow the latest trend of technology. Business users grew steadily more frustrated with these barriers that limited their capacity to make change promptly, and as technology evolved, they began to buy and build localized systems themselves. This left many businesses with hundreds of systems linking in an unmanaged manner without real documentation. During this period, the systems analyst role evolved to the business analyst. The new role requires more than documenting process and applying technological expertise.
Renee, nice predictions. I think you are on the money here. It will be interesting to look back in 2ish years and see if the trend plays out.