How many times have we heard there’s no place for a Business Analyst in SCRUM teams (or other Agile frameworks)? Even better: when someone asks if your company works with SCRUM the answer usually is “Yes, we do, but I’m not part of the SCRUM team!”.
Fortunately for me, I’m a Business Analyst and I’m part of the SCRUM team within my company. And from where I stand, a Business Analyst role is important regardless the methodology in use, especially in any software development project.
A SCRUM team is multi-disciplinary; it must include all the necessary skills to deliver each sprint. A Business Analyst can take on a role within the development team or play the role of Product Owner, depending on the needs of each team. I’ve been in both situations.
According to Scrum.org “A Scrum Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team.” This means his main goal is to deliver value and to do so it’s important to understand the customer’s business, its processes and needs, establish the main objectives and prioritize. Finally, using the time and budget available to deliver the maximum value with the help of the development team.
I can’t help but think that it’s the same definition of a Business Analyst and that on SCRUM the Business Analyst is the Product Owner!
After understand the customer needs, a Product Owner (Business Analyst in SCRUM) is responsible for:
- Feed the product backlog which is the artifact that represents the understandable object; it is what represents all the necessary changes to maximize the value to delivery.
- Identify which backlog items will bring the most ROI possible to the customer’s business, prioritizing the backlog items.
- Follow up with the customer on every interaction, so he can know if what’s being delivered is really bringing value and help him understand how to increase processes performance.
- Ensure that each item of the sprint backlog includes all the necessary information, so the development team can address all customer’s needs.
- Know how to say NO to the customer and the development team when needed, be realistic and make decisions.
You also hear that SCRUM has no functional specifications because the team must be agile. But does this mean that an agile team can’t grab a piece of paper and pencil and draw a context diagram, a process or an algorithm, to better understand what to implement? Is it required that the solution is in everyone’s mind to be an agile team? I’m sure it will depend on the needs of each project but for me it works this way:
- What documentation will bring value to the customer?
- In what way the development team will have better understanding of the job in hands?
- Documenting in detail will bring further value?
Only when answering these questions, I can decide on how to detail each backlog item. The specification of a functionality can be a user story, a flowchart, a state machine, an entity diagram, a use case, a picture of a paper drawing and so many other things. The Product Owner is responsible to analyse and decide what make sense and each situation.
When is clear that the Product Owner cannot deliver all specifications needed he could decides to include a Business or Functional Analyst in the development team. They can assist in product specifications tasks and even in the quality assurance process (specs, test specs and test execution). This means that whomever takes this role becomes part of the development team, having tasks assigned in each sprint. The detailed specification of a feature must be made in previous sprints prior to the feature implementation or even in the same sprint.
Same applies to the test process; it’s the Product Owner’s job to prioritize each task in order to maximize the delivered value, as well as the deployment team productivity.
By using SCRUM we’re able to iterate, delivering smaller chunks and getting feedback along the way on how customer needs should be addressed.
If we compare traditional approaches with agile methodologies, what are the main differences for a Business Analyst? According to Dave Saboe, the way to change the mindset of an Agile Business Analyst is:
- understanding that conversations matter – conversations are more important than documentation.
- expect change – In a traditional environment, you want to manage change. In an Agile environment, you expect change.
- Focus on customer value – Understand what the customer wants, his needs and exploring various options, being able to prioritize work based on that value.
- Do just enough just in time – Instead of getting a big design up front before we move along, we work in small increments doing just enough just in time.
- Have a team focus – I need to stretch my skills, step outside my role, and see what kind of support the team needs. On an Agile team, we succeed or we fail as a team.
- Have a bias towards action – We do just enough analysis just in time and then take action.
Value… I’m always talking about value: SCRUM it’s about Value! Business Analysis it’s about Value!
Márcia Catarino
Polarising Business Analyst
-
Márcia Catarinohttps://polarising.com/author/marcia-catarino/
-
Márcia Catarinohttps://polarising.com/author/marcia-catarino/
-
Márcia Catarinohttps://polarising.com/author/marcia-catarino/
-
Márcia Catarinohttps://polarising.com/author/marcia-catarino/
Great!