My day job. What a BA does between projects

In the world of Agile Scrum, the Sprint is King.

Two weeks to get a selected amount of work done and demonstrated to the customer. There are articles and books galore about how to determine the amount of work that can be done…team velocity, planning poker, random number generator, crystal ball…, but very little discussion about how the PO (tonight, the part of the BA will be played by the PO) is supposed to get the User Story Acceptance Criteria (pinch hitting for Requirements…number 42, Acceptance Criteria!). There’s backlog building and grooming and Sprint planning, but where does the information that goes into the building and grooming and planning come from? Talking with the customer, of course. After all, they’re the ones who know what they want, right? (That’s a story for another time).

When I took my first tentative steps into Agile Scrum, I was horrified to learn: A) that I was expected to create User Stories with Acceptance criteria for the Backlog Grooming session out of thin air, B) that those User Stories would represent two weeks’ worth of work for the team and C) that that work was to be demonstrated to the customer at the end of those two weeks! What were these people drinking? How was I supposed to go to my customer and ask for two weeks’ worth of requirements? “Hi, I’m here to get your requirements for the SGP (Super-Giant-Project), but I only want to know what you want to see a week from Friday.” “Oh, and I’ll be back on the following Monday to ask you again…and again…and again.”.
That can’t be right. How would I get any sort of understanding of the business process two weeks at a time? The answer is, of course, you don’t. Whether you call yourself a BA or a PO, or just an interested party, you need to have some level of understanding of the processes that are going to be impacted by your SGP. You don’t need to know every little detail about every little step in the process, but you do need to know if Step 27 sends information back to Step 3. This is where what I call “My Day Job”, comes in.
My Day Job consists of those activities that happen outside the execution of a formal project. You know, those 10 minutes between the signing of the Project Charter and the first Kick-off meeting. This is the time to set the groundwork for the tasks you’ll need to define for each Sprint. “But Mike”, I hear you say, “the customer knows their process, and they’ll be in the Scrum meetings”. They do, and they are, but I’ll bet they don’t know that the data from Step 27 needs to flow through 6 edge firewalls, 2 app zone servers, a DB proxy and my uncle Frank’s Facebook page.

As BAs, excuse me, POs, we know how to capture current-state and recognize those critical processes that require more understanding. THAT is my Day Job – To come to the Scrum table with a mid-level understanding of the processes we’re about to change. Do I need to know about the afore mentioned DB proxy? No, but I, and the developers, do need to know that the data I need in Step 3 comes from far away, through a lot of flaming hoops.
In the first meeting with the Scrum Team I draw a horizontal line on the whiteboard. Above that line I draw little boxes with arrows in-between and a big arrow going from the last box back to the first. Below that line I draw lots of circular arrows. My Day Job is above that line; Agile development is below. When the team decides where to start, I can look at my notes (e.g. BPMs, Use Cases, etc.) of the business processes and drill down deep enough, and in the right place, to write meaningful User Stories that define what the business needs, and highlights what the developers need to know (i.e. flaming hoops). Now I’m ready to feed the Agile development beast.

Of course, the hardest part of my Day Job is getting the time to do it. If you’re fortunate, you get a few weeks’ notice before the kickoff, so you can talk to the business. If you’re really, really, fortunate, your boss will shut down project work and have all the BAs in your group draw BPMs for 5 weeks (this actually happened to me! I miss that guy…). Reality, of course, lies somewhere in-between. Any current-state BPMs or process designs you can create will not only help with defining the User Stories for today’s project, they are a great for identifying the pain points and opportunities that could be the impetus for tomorrows.

I sleep much better now that I know I don’t have to do my job 2 week at a time.