Business Analysis Homebase

Quick Terms

• BA = Business Analyst (if you’ve not seen that everywhere)
• PO = Product Owner
• PM = Project Manager
• Ticket/Card = A documented request for a piece of work, mapping to the levels on the right

Structuring the work

Agile breaks the work into these components, which may then be represented by a Ticket/Card:

• Initiative: [OPTIONAL] The title of the project at hand. Used in Jira and SAFe, but not generally in the wider framework.
• Epic: A high level deliverable e.g. “Incident Management Capability”
• Feature: An optional level below epics to track specific functionality e.g. “Incident Logging Screen”
  • “Why can’t I find this in Jira?” Good question. Jira for some reason wanted to do it differently. This made a lot of people mad. Useful to know it exists.
• User Story: The high level requirement that the Product Owner writes to give direction to the development team. Formatted in the “As a ___ I want/need ____ So I can ___” e.g. “As a Service Desk Operator, I want a notes field, so I can include any additional information the caller provides”. This tends to also include acceptance criteria, and some ideas around testing.
  • The team will assign values around difficulty later.
• Task/Subtask: [OPTIONAL] The individual personal-level bits of work created and completed by a developer. These can be used by devs to help track their own work if they think it’s valuable. e.g. “Add a free text notes field to Incident Logging screen”

Scrum

A software development framework where a small team of 4-11 people (7 recommended) work together to provide value to a PO who sets the direction, with a Scrum Master running ceremonies and removing blockers/impediments to the team’s progress. The team operates on a fortnightly (recommended) basis called a sprint, completing work from the POs backlog and providing value at the end of the sprint. The team itself is responsible for setting the pace and the PO is responsible for setting the general direction. Whilst it was designed for software development, you’ll find it used in a range of settings to mixed degrees of success.

Ceremonies?

There are 4 main meetings/workshops that are run across the sprint often called ceremonies, and the 5th that is often forgotten as it occurs out of view:

1. Sprint Planning: the Product Owner provides a series of stories from their backlog for the team to work on. The team takes the opportunity to review, question, estimate the effort in “story points” (an abstract measure of difficulty), and accept or deny based on how much capacity they have in the sprint, and their ability to work on it. It is recommended that this time be used to define a “Definition of Done” for a story, and some teams like to create a “sprint goal” as part of this to stay on track.
   1. “What do I do if the stories are unclear!” Awesome, that’s the point of these discussions, breaking down the stories into the actions required to deliver them with the team responsible for delivery, and sometimes you may even need a “Spike” which is a sprint dedicated to prototyping and research.
2. Daily Standup: A maximum 15 minute long meeting, where each member is asked 3 questions by the Scrum Master – “What did you do yesterday”, “What are you doing today”, “Are there any blockers/impediments you need help with?”
3. Sprint Review: The team demonstrate the work prior to the end of the sprint to the PO, ensuring there is value created and the intention behind the story provided has been met. These may also be called a “showcase”
4. Sprint Retrospective: The team get together to discuss continual improvement for the process and the team itself. The meeting normally involves been asked 4 questions facilitated by the Scrum Master – “What went well”, “What went poorly”, “What can we change”, “What should we continue to do”. Honesty and trust are recommended in this to make genuine change.
   • Online tools like Miro, Mural and Mini Retro may help facilitate there.
   • If the Product Owner is defensive or holds substantial authority over the team to the point that they do not feel comfortable providing honest feedback, you may find it easier to run the retrospective without the PO and pass feedback through the Scrum Master. This is an option but not a recommendation.
5. The one we don’t talk about enough, Backlog Grooming: The PO, sometimes with assistance from a BA, will go through the items in their personal backlog which is not generally seen by the Scrum team, and do several actions, including adding detail to a particular story/item, re-ordering by ever-changing priority, removing or archiving no-longer required items, etc. This must be done prior to sprint planning in order for a useful sprint planning to occur, and stories to be provided that are at a sufficient standard for a developer to independently action without further questions/concerns. Reminder, the PO doesn’t estimate the work, only the Scrum team does that.

Kanban

Commonly used in concert with Scrum, a Kanban Board is a 2D representation of the movement of tickets across their lifecycle from backlog to completed with verification from the PO.

This is typically represented in vertical columns, with some common titles being; Backlog, Ready, In Progress, In Review, Done. As a ticket is actioned, it is put in ready by the PO, pulled into In Progress by a dev where it is actioned, once done it moves to review for the PO to sign off on, then into complete to mark everyone’s agreement. Tickets forward through stages, and new tickets are created as bugs are found or blockers emerge. As stories progress, they’ll likely split into smaller more manageable chunks (tasks) that the team can easily tick off, and that’s great.

Kanban itself is a methodology of limiting the work in progress, by having strict limits on the work that can be in motion at one time, thus preventing work from stalling before more work can be pulled from the backlog. As noted above, the Kanban board is what most people tend to use.

SAFe

The Scaled Agile Framework. A methodology of running multiple Scrum teams concurrently on the same product. A “Release Train Engineer” functions as a Product Owner across the Product Owners, directing them and aligning their work through Product Increment (PI) Planning. Additionally, Scrum Master’s meet to work together and share advice in a “Scrum of Scrums”.

It has very mixed opinions, and can be a heated topic at the best of time, ranging from “It’s a layer of waterfall over agile practices which slows everything down” to “a complete waste of time, money and effort” to “it’s essential to running a large organisation”. Your experience may vary.

How does a Business Analyst fit in?

Scrum formally doesn’t have a BA role. You have the scrum master (enable the work), the product owner (set the vision) and the developers (actual workers). By textbook, the BA function should be completed as part of the product owner role, as they set the vision, and the team decline/reject stories without sufficient detail or consideration.

In the real world, POs often don’t get training, don’t have the BA skillset, and rarely have the bandwidth because dedicated POs are surprisingly rare outside of multinational organisations. It’s also quite often that the Scrum Master role isn’t a dedicated role, so it often falls down to the BA to fill the gap. With that in mind, does a BA belong in a scrum team? Yes and no. It can be better to have a team of BAs across all POs if they need to leverage them, but you may want a dedicated BA to supplement (and act on behalf of) the PO, answering questions on their behalf and doing investigation for both Devs + PO, in which case it makes sense to embed them within the team. Neither approach is perfect, and it’s something Agile and the BA profession are still working through as we transition to Agile across more industries.

BA as Scrum Master

Whilst not recommended, it is common for all the reasons highlighted above. So in reality, you might want to know how to run things. Get a team, book in 2 weeks, book in meeting starting with sprint planning (day 1) and ending with the retrospective (day 13). Hopefully you’ll have a product owner with a clear vision, who can write up a broad strokes idea of the tasks/items required in order to achieve their mental image of success, and get them to put them in order of priority to deliver. Take these top items to the team plus product owner at sprint planning, and have them discuss if it’s possible to do these actions, why or why not. Have the team discuss what needs doing, and the product owner verify if that is their intent, if they’re not available act as the delegate for the PO. Once work is broken down, decide how much you can commit to, and lock it in for the sprint. Every day, you’ll meet in the morning and discuss 3 questions: What did you do yesterday”, “What are you doing today”, “Are there any blockers/impediments you need help with?”. Any further discussion, save it for the end of the meeting. At the end of the 2nd week (day 12 or 13) run your sprint review; you should have something built or at least an idea, so present that to the product owner for feedback so you know you’re going in the right direction. Take that feedback, and save it for the next sprint planning. Finally, get the team together (no PO) at the end of the 2nd week (day 13) and ask them 4 questions: “What went well?” “What went poorly?” “What should we start or continue doing next time?” “What should we stop doing?”. Congratulations, you’re a 1 paragraph educated Scrum Master!

Stefan Carton

Updated: 2/08/2022