Scale

Measuring the Analysis Process

I’ve previously written about measuring requirements and business analysts. I am concluding the series with my current thoughts on measuring the analysis process.

What_gets_measured_gets_done

This quote is a truism is because it’s how we work. Measurements help us identify areas we should focus on or improve. Measurements let us know when we succeeded, or not. I love the idea of measuring BAs and yet, I have spent years balking at the idea of measuring requirements and BAs. It doesn’t work very well in practice.* I had cause to rethink the how to measure BAs when one team I worked on took down the following action item, “Decide (if,) how and what BA velocity to track.”

512878595_dae3c75aab_o

Measuring Business Analysts; Don’t KPI Me

Good managers often ask, “How do I know my team is performing well? How can I spot which folks need help? Who should I reward for a job well done?” In today’s busy world, where managers have significant responsibilities in addition to nurturing their team, measurements and metrics can be a a help.

Unfortunately, it is really easy to measure analysts poorly.

book jacket

Read “Discover to Deliver”

In Discover to Deliver: Agile Product Planning & Analysis, Ellen Gottesdiener (author of The Software Requirements Memory Jogger and Requirements by Collaboration) and Mary Gorman tackle one of the largest problems facing Agile and Scrum software projects, how to successfully integrate the ideas and tools made so popular over the last decade into working, valuable solutions.

LaoTzu(310x398)

Test Driven Retrospectives

TL;DR: Retrospectives can lead your team to becoming a powerhouse. One method of ensuring you making real improvements is Test Driven Retrospectives, where you define the desired state during the retrospective. By writing provable statements ahead of working on the task, you ensure everyone has the same understanding and knows what successful change looks like.

easy-button

Agile User Stories Are Easy (IIBA Fort Worth)

I had the pleasure of speaking to the IIBA chapter in Cowtown last night. That’s Fort Worth for those of you unfamiliar with the Great State of Texas.

Total attendance was 15 people and we had some good conversation. There were not many questions during the presentation, but enough to let me know they were listening. I was touched a few folks from the IIBA Dallas chapter drove over for the meeting, thanks.

Holly Millet, a guest at the event, was kind enough to run the camera and record my presentation. If you are interested in seeing this, then please let me know and I’ll put it online and provide a link.

This presentation is at an introductory level, aimed at Business Analysts who have not worked in an Agile or Scrum for a significant period of time. I do not by any means cover everything it means to be an Agile BA, but rather focus on the elements of good stories, including writing Acceptance Criteria in a Given – When – Then format. This latter section should provide some value for anyone not already involved in the format. Unfortunately, with only an hour, I include enough content to push out interactive activities.

In August I coined the term Behavior Based Requirements to describe Given-When-Then and some of the related concepts to BAs. If this is your first introduction to this format for capturing and communicating value, you can find much more information on my resource page here.

As usual, I am posting a version of the slide deck here for attendees who want to view a copy of the slides. I typically shift the slide order just a tad to make more sense for reading at your desk. This slide deck includes references and mentions the mighty shoulders I stand upon when presenting.