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.


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.


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.

Tech Training–Hour of Code, CSS3 Selectors, new Team Goal

TechTrainEvery Friday our team meets for two hours to work on something together. We’ve scratched the surface of many topics to get a feel for what is possible and dug deeper into others that we want to implement on our project. The adjacent mind map shows about a year’s worth of training (taken from our PM’s whiteboard for his talk on why we do technical training).


Hour of Code

Today our PM presented some things his young daughter did in the recent hour of code – a fantastic event to get kids (and adults) interested in programming. We also took a look at the similar Santa Tracker by Google where like an advent calendar there’s a different programming game or puzzle available every day in December leading up to Christmas. We had a ton of fun navigating our elves through mazes and flying them through the sky to pick up presents.

CSS3 Selectors

We’re always looking into fun ways to practice our skills, and what better way than a rewarding little game of CSS3 selectors! If you do any web programming, you should try this out: It took our group anywhere from 30-45 minutes to complete the 26 challenges and along the way you could hear many quiet refrains of “Yes!” and “oh-yah!”. It’s great to hear everyone having a great time and learning, too.

I gave the team some more resources to read up on in their own time, too:

Docs -

Interactive -

Tutorials - (work through the menu on the left or click Next Chapter)

Team Goal

Our team works on personal goals and team goals. An example team goal was to upgrade our source code tool (TFS) and development tool (VS) to the latest versions. That took a major effort because it ended up getting bundled with an operating system upgrade (Win 8.1) and pushed out across our organization.

During the last 20 minutes of our tech meeting today we brainstormed what our next team goal should be. It needs to be something that takes a few months to a year and benefits the whole team.

We put up a list on the whiteboard as we brainstormed, and then each team member emailed me their three votes from the list (and they could vote more than once for any idea). The final tally of votes was:

  • Kendo UI upgrade (4)
  • MVC 5 upgrade (3)
  • EF6 upgrade (2)
  • SQL 2012 upgrade (0)
  • Visual studio upgrade (0)
  • Requirements Gathering/Analysis training (6)
  • Mainframe administration training (2)
  • JavaScript testing/improvements in our project (2)
  • Move automation/dev ops for better continuous integration (2)

I was excited to see the team want to work on requirements gathering and analysis training because I really enjoy those (I’ve given a couple of talks and am working on a Pluralsight course on the subject), and because it was one of the soft skills in a team who really loves the tech-side.

We’ll work on how to learn about a problem from our customers, how to ask why enough times to find out the real business reason, practice how to come up with a good plan for a complicated process, and more. We’ll watch some Pluralsight courses and dedicate some training days to getting better – I can’t wait to get started! It’s so good to get a direction set by the team that you know has the whole team’s buy-in; everyone wants to get better, we just need to provide the right environment to make it possible.