Rusty Divine

Live, Love, Learn, Teach

Business Analysis / Requirement Gathering Exercise

goal settingRecently the software development team that I lead decided on a new team goal to work on together – improve our business analysis and requirement gathering skills.

The Project Manager of our team, Brad, had an idea that he could be the customer for a software project that he actually wants built – something that will add a set of user stories and tasks to our Team Foundation System (TFS) for him. This takes him a few hours each iteration, but more importantly he just dreads doing it because it should be easy to automate.

Here is the text email I sent to the team earlier this week:

We have a fun exercise to work on requirements analysis that we will be starting this Friday during our tech training session. Brad has an idea for a real piece of software he wants to use (it has something to do with TFS tasks) and he wants us to help figure out what this thing is and what it should do.

Agenda:

We will break up into two groups so that we can spread the learning out. This is not a competition, but the two groups should work independently so that everyone has the opportunity to struggle a little.

Blue Team: Suma (Team leader), Ryan, Padma, Rusty

Green Team: Adam (Team leader), Dan, Satish, David

The team leaders will decide how to organize the team and should take the lead responsibility in getting the requirements right. Rusty and David will take off their tech lead hats and play the role of team member suffering from minor and temporary business analysis amnesia (basically we’ll try not to steer so that others can exercise their skills).

  • 10-10:30ish – Brad will present the overview of his idea to both teams.
  • 10:30-11 – Brad will “leave” the room (pretend he isn’t there), both the teams will independently organize and decide what questions they have and how they want to proceed
  • 11-12 – Brad will actually leave the room. The teams will take turns of no longer than 15 minutes to ask Brad follow-up questions and do whatever work they see fit in defining the project.

At noon we’ll assess where we’re at. It’s quite likely that we’ll need to spend most or all of next weeks’ time (and even more?) doing analysis.

When a team feels like they are ready to go, they can present their plan to Brad and he can decide whether or not he wants to sign off on it. If not, revise the plan and re-submit.

Each team will then actually build their version of the tool during tech training time in the following weeks. There’s no better validation of your requirements gathering than having to build what you defined! We’re not sure how much work will be involved at this point, so we’ll adjust as necessary.

In the coming weeks we’ll also spend some of the time during each tech training working on quick business analysis exercises or demonstrations. I may also send out some 15-minute drills occasionally that you can do during the week.

By the time we wrap this all up in a few months, we’ll do a retro of how this initial requirements went considering the things we’ve learned along the way. We may do a final requirements gathering exercise like this first one using the skills we’ve learned, but likely won’t build that project.

</eom>

Blackboard time quality moneyThe first meeting was pretty fun. I had a good time sitting back and letting everyone else on blue team take the lead in eliciting the requirements from Brad.

Next week the team will get an email every morning with a practice exercise that shouldn’t take more than 15-20 minutes; I’ll post them here, too. They will cover things like, “What is the Project Management Triad?” to give each of them a chance to think about requirements daily.

blog comments powered by Disqus