No, it’s not yours. No matter what you may think, the story just isn’t yours. You may have a hand in it, you may even pick it up off the backlog and start working on it, but really, it belongs to the team.

As a Business Analyst on an Agile project (or indeed, on any project), it’s your responsibility to understand the requirements of the client and translate them into workable bits of functionality that the team can build from. Yes, these bits of functionality are called stories, and they usually follow the format “as a [something] I want to [do something] so that I can [achieve some valuable result]”. We all know this drill by now. What I see everyday though, are BAs struggling to flesh out the entire story by themselves. Hello there! No one said you couldn’t ask for help! That’s what the team is for!

I’m currently working on a large project where we are working with the clients development team, including developers, UXers, and BAs. Most of these people come from the traditional waterfall method of working and it’s clear from the BAs that we work with that collaboration is not high on the priority list in waterfall. Oftentimes the BAs will pick up a story and not come away from the computer until a few days later, when pretty much the whole story has been done. This is the area where we end up doing most of our coaching work. We spend our time trying to get the BAs to work with the other team members. Pairing with them on writing the story and getting the format right, the acceptance criteria well structured is the first challenge (which is a topic for another post…) but changing a BAs mindset to let go of the belief that they need to figure out the entire solution by themselves first can be much trickier. Coming from a more traditional (read Waterfall) background myself, I know how difficult it can be to let go and allow the team to help scuplt a solution. The BA is supposed to know everything, right? Wrong! The BA should be trying to use the expertise of the whole team to come up with the best possible solution. Each member of the team has unique experiences and specialities and tapping into these allows you to sidestep potential hurdles easily and avoid unnecessary rework.

The first bit of collaboration you’ll do on a story is to figure out what the heck it’s all about. Who do you go to for this? The Product Owner. This should give you a good understanding of the direction/s the story could go in.

After this, there is sometimes a period when you you may need to do some thinking by yourself, if that’s your thing. Sometimes you’ll need to make some calls, gather some information, before you can start sketching out the requirement. But this shouldn’t go on for too long without checking in with someone else to bounce your ideas off of. An important port of call is the developers in the team. They’ll be able to give you guidance around any technical hurdles you may not realise are lurking under the hood. Close on the heels of the devs, you should definitely be speaking to the UX team to give them the scope of the story and let them start throwing together some wireframes for the Product Owner to start workin with and testing through. A check in with the QAs on the team can uncover interesting edge-case scenarios that you never considered, as well as requirements for test data that needs to be prepped and which may take a while to do so. Better get that ready ASAP!

Some BAs pick this up faster than others. Those with larger egos tend to find it more difficult to let go. Some still believe that the roles in a team are clearly defined: “I’m the BA, so I should be creating the solution first and only when it’s completely worked out should I just double-check it with another BA.” WRONG ATTITUDE! Everyone on the team is working towards the same goal, albeit from different perspectives. A good BA is able to effectively harness these perspectives and distill them into a great story. And don’t we all want to tell a great story?