DAY 5 | The Data Analysis Toolkit: Your Practical Reference Guide This is a reference guide, not an argument. It pulls together everything from this week into a single place you can return to whenever you are working with data. If you followed the series from Monday, this is the distilled version. If you are arriving here first, each section stands on its own well enough to be useful immediately. The Mindset Before any technique, the foundation of good data work for a Busines

DAY 4 | From Data to Decision: Turning Numbers Into Analytical Judgement There is a comfortable myth that data makes decisions. It does not. Data informs decisions. People make them. And the gap between having data and making a good decision is wider than most organisations admit. It is entirely possible to be data-rich and decision-poor, to have dashboards full of metrics and still make choices that the data does not support, because nobody did the work of turning the number

DAY 3 | Interpreting Data Honestly: Avoiding the Traps That Mislead Here is a single fact about a business, presented two ways. Version one: customer complaints rose by 40% last quarter. A serious problem that demands attention. Version two: customer complaints rose from 10 to 14 last quarter, against a total of 50,000 transactions. A negligible change well within normal variation. Both statements describe the same data. Both are factually true. And they lead a reader to comp

DAY 2 | Reading Data: The Foundations Every BA Must Master Before you can interpret data, you have to be able to read it. And reading data properly is a skill that most Business Analysts never formally learned. This is not a criticism. The path into business analysis rarely runs through statistics. Most BAs came from business roles, from operations, from project work, from domains where data was something you received rather than something you analysed. The foundations of rea

DAY 1 | Why Every Business Analyst Needs to Be Comfortable With Data I want to start with an admission that took me a while to be comfortable making. For the first few years of my career, I avoided data. Not consciously. I would not have described it that way at the time. But when a project involved numbers, I gravitated toward the parts that did not. I was comfortable with process, with requirements, with stakeholders, with documentation. When a report full of figures landed

DAY 5 | The Process Improvement Toolkit: Your Practical Reference Guide This is not an article you need to read from beginning to end. It is a reference guide. The kind of article you save to your reading list, return to before a process improvement workshop, and use to remind yourself which tool fits the situation you are in. Everything covered in this week's series is here, organised for practical use rather than sequential learning. If you missed any of the earlier article

DAY 4 | Leading an Improvement Initiative: From Discovery to Implementation Analysis is the part of process improvement that most BAs are comfortable with. The workshops, the mapping, the root cause investigation, the future state design. These are activities that sit squarely in the BA's core competency. They are structured, analytical, and produce tangible outputs. Implementation is the part where most improvement initiatives quietly die. Not dramatically. Not with a visib

DAY 3 | Lean Thinking and Kaizen: The BA's Guide to Continuous Improvement Lean thinking originated in manufacturing. It was developed at Toyota in the decades following World War Two, as a response to the challenge of producing high-quality vehicles with limited resources in a recovering economy. The Toyota Production System, from which Lean thinking is drawn, was built on a single obsession: eliminating everything in a production process that did not directly contribute to

DAY 2 | Root Cause Analysis: Finding the Real Problem There is a pattern I have seen repeat itself across improvement projects in different industries and different organisations. A problem is visible. Management asks for it to be fixed. A team is assembled. They look at the problem, discuss it, and design a solution based on what they can see. The solution is implemented. The problem either returns or a new version of it appears somewhere else in the process. The reason is a

DAY 1 | Why Process Improvement Is a BA's Most Powerful Skill I want to tell you about a warehouse operations team I worked with early in my BA career. They had a goods-in process that required three separate sign-offs before any delivery could be accepted. Each sign-off came from a different department. Each department had different working hours. The result was that deliveries regularly sat in the loading bay for hours, sometimes overnight, waiting for the third signature t

DAY 5 | Agile BA in Your Career: Mastery, Interviews and the Six Principles to Keep We have covered a lot of ground this week. Day 1 established what genuinely changes when you move into an Agile team and the identity shift from document-producer to embedded analyst that determines whether the transition goes well or badly. Day 2 went deep on user story writing. INVEST criteria, acceptance criteria in Given-When-Then format, writing for edge cases, and the five story-writing

DAY 4 | Working With Your Product Owner: The Relationship That Drives Delivery I have worked in Agile teams where the BA and Product Owner relationship was genuinely excellent. The Product Owner set the direction. The BA translated it into requirements. Each brought something the other did not have: the Product Owner brought authority, strategic context, and stakeholder relationships; the BA brought analytical rigour, requirements expertise, and the ability to translate a bus

DAY 3 | Backlog Refinement and Sprint Ceremonies: The BA's Engine Room There is a version of Agile BA practice where every ceremony is something that happens to you. Sprint planning happens, and you answer questions when the team asks them. The standup happens, and you give your update when it is your turn. The sprint review happens, and you sit in the room while the developers present. The retrospective happens, and you nod along. This version of the role is passive. And it

DAY 2 | Writing User Stories That Actually Get Built Right Here is a user story I pulled from a real project backlog. As a customer, I want to be able to manage my account, so that I can keep my information up to date. The format is correct. The syntax is right. It would pass a cursory review. And it is completely useless as a development requirement. What does "manage my account" mean? Change a password? Update a billing address? Close the account? View transaction history?

DAY 1 | The BA in an Agile Team: What Really Changes I want to tell you about the first week of my first Agile project. I had come from a Waterfall background. I knew how to produce a Business Requirements Document. I knew how to run a requirements workshop, baseline a specification, and manage a change control process. I was good at it. And I walked into that Agile team expecting to find an equivalent set of activities that I would now do differently. What I found instead wa

DAY 5 | Requirements Excellence in Your Career: Mastery, Interviews and the Six Principles to Keep We have covered a significant amount of ground this week. Day 1 established the foundation: the real cost of poor requirements, the difference between documenting and discovering, and the mindset shift from scribe to analyst that changes how you approach requirements work entirely. Day 2 went deep on elicitation: the six techniques that find what stakeholders cannot easily artic

DAY 4 | From Discovery to Sign-Off: Managing Requirements Through the Lifecycle There is a version of requirements work that ends at sign-off. The BA completes elicitation. They write the requirements. They run the review sessions. They get the document approved. And then, to all intents and purposes, requirements work is done. The document goes into the project repository. The team goes into development. The BA moves on to the next engagement. This version of requirements wo

DAY 3 | Writing Requirements That Hold Up: Functional and Non-Functional in Depth Requirements writing is a craft. Not a task. Not a deliverable. A craft is something that takes genuine skill to do well, that can always be done better, and that produces noticeably different outcomes depending on the quality with which it is practised. Most Business Analysts learn to write requirements by exposure: reading other BAs' documents, following templates, and gradually developing a s

DAY 2 | Elicitation Mastery: Getting to the Real Requirement There is a concept in cognitive psychology called tacit knowledge. It refers to knowledge that a person holds and uses effectively but cannot easily articulate when asked. The experienced nurse who knows a patient is deteriorating before the numbers show it. The master craftsperson who adjusts their technique in response to feedback they cannot describe. The subject matter expert who has been processing insurance cl

DAY 1 | Why Requirements Fail & What Excellence Actually Looks Like I want to tell you about a project that almost destroyed a team. Not a small internal tool. A customer-facing platform that had taken eighteen months and a significant budget to build. The business had waited for it. The marketing team had planned campaigns around it. The go-live date had been communicated to customers. Two weeks before launch, the head of operations sat in a review session and said four wo