- June 8, 2016
- Author: admin
- Category: Agile Methodology
As an Agile Business Analyst, nothing is as simple as it looks. I know it, and I enjoy the challenge of being one. For starters, I am often asked if I do anything but write stories out-which anyone who knows English can easily do (we’ll come to stories in a minute). And it takes me a while to explain to skeptics and others alike, of how challenging my job actually is. Playing proxy customer is not easy, after all.
For the uninitiated, quite a lot of Agile work is done using stories as the base. A user story is the smallest level of detail a feature or requirement is broken down into. This smallest chunk is derived in such a manner that it can deliver a piece of business critical working software to the client.
As soon as a client (who has a business problem) approaches an Agile team for help, a series of activities is kicked off. In Agile terms, this is called an inception.Before knowing what the inception is, it is critical to understand the inception team. This team consists of the most critical stakeholders: the Clients (Product Owner), the Project Manager (PM), the Developers and Technical Architects(Devs), the Business Analyst (BA), the User Experience Consultant (UX), and sometimes the Quality Analyst (QA).
An inception includes brainstorming, user journey definitions, discovering possible solutions (and shooting them down), and deriving a high-level feature list, amongst many other activities. These features are then broken down into logical deliverable stories, and a Master Story List is obtained. Of course, with the passage of time, the stories in this list might be removed, or new ones added, as in Agile no one really knows what will change, and when. Against each story that is identified, I might add comments as necessary to describe the story. This will help me flush out stories in the right context.
As an Agile BA, I am the driver of this inception bus. I am responsible for drawing up a schedule, and running these sessions. A lot of my work revolves around these stories too. Working through the inception deck, I do a lot of data collection. I collate information from the brainstorming, organize it and derive journeys. I cut the journeys down into many, many small parts that will make the smallest chunks, but deliver business value to my client. This activity is called story slicing. I get this validated with my team of developers and project manager to check if my slicing makes sense.
The team and I then go about doing guess-timations. Yes, I’d rather not call them estimates yet. These guess-timations help the Agile team know when this project can ‘potentially’ be completed. Each story is assigned a story point. The story point is a measure- like numbers or t shirt sizes that gets equated to some rough working days. We estimate all the stories with points and keep them ready.
We derive something called the ‘velocity’ at which the team will work, and how much they will deliver per iteration. An iteration is the duration a team will take to deliver chunks of working software- it may vary anywhere between a week and three weeks.
A prioritization exercise is done with the client, where I write all the story cards and lay them out (yes all of them). We then go about arranging them into stories that are must haves, should haves and nice to haves, and into lanes when we might ‘potentially’ deliver them.
A rough release plan is drawn based on the number of people working on the project, the story points and the velocity at which the team will deliver the stories. This will give the clients a fair understanding of when they can expect to get full working software.
Once all this is done we sign off happily on the high-level scope and plan. By this we are not committing to anything yet. We are only saying that these are the features we will deliver, but are open to adding more (depending on time and budget of course).
Project execution begins here. We then start picking the stories for development. Every week, the team delivers a set of stories based on prioritization. So for the team to begin delivering in week 1, the BA has to be one or two weeks ahead.
I write the stories out a week or so in advance and run it past the client. Since a story is something that will fit into an index card, the client will be able to review a story in minutes (as opposed to 300 page business requirements documents).
Every line item of the Master Story List (which I am the master of) gets translated into full-fledged stories. This is my masterstroke – I write more accurate more detailed information on the story and I don’t get tired, because I am not writing a document. I write about 6-10 stories a week amongst doing other things.
A story contains a few essential parts:
- A user story line, some acceptance criteria, notes on what to test and any related tasks that need to be captured.
- A story line is an interesting one liner that describes what a user will expect to achieve. For example: As a user of the ticket reservation system, I would like to search for possible flights to a destination, so that I may compare options and choose the best option.
- Acceptance Criteria define what steps must be taken to deliver this story. This is written in simple English, and is usually mapped to some part of a user journey.
The notes to test describe what are the touch points the QAs (and the developers) need to be aware of while testing the story.
The Swim Lanes
The story card has a short lifecycle- and it has to brave many a strong current before it is signed-off by the client. In simpler words, a story passes through many stages before the client signs it off.
The lanes are:
Backlog: When a story has no acceptance criteria, and is yet to be analysed.
Analysis and UX: acceptance criteria are written and hi-fi mocks are prepared, and are used by the development team as references
Kickoff Just before developers pick a story, I do a kick off for that story, explaining to the developers the intent of that story and what I expect to see as a developed story
Development and UIEnsure the acceptance criteria are coded and unit tested.
Volleyball Once the unit test is done, the BA does something called the story volleyball-which is essentially a first level functional test before the QA tests it.
QA and Approval If it passes the volleyball, the story moves on to QA and then to the client for approval.
The clients and the Agile team fix up a time every iteration to showcase that iteration’s work. This ensures that even before the client has to actually approve the story, they get a feel of how the story has spanned out. This way, if they are not happy with any visual component or working, their feedback is instant and the team can fix it before it is sent for approval. I ensure that any feedback is tracked, developed, volley-balled, and tested before the story is sent for approval.
Apart from all of this, I co-ordinate regularly with clients (sometimes even everyday) with queries that my team or I have with respect to the stories we have at hand or the release dates. I have to do all this with a delicate balance- I must negotiate-with developers, clients and managers in order to ensure timely delivery.
My hands are full. The Agile workplace is fast paced, and it is challenging. And that keeps me going. The Analyst, the driver of this crazy bus!