The conference title is Skills for Success: Evolving as a Business Analyst and my presentation is “How to Use Behavior Based Requirements to Build Understanding & Save Your Project.”

The event is on Monday, April 15 at the Earle Brown Heritage Center outside of Minneapolis (registration link). This is one of the premiere PDD events in North America and I am honored to be speaking. If you are in the area, please come, engage, and learn from the outstanding speaker line-up and local BA community.

Post conference update: Here is the published version of my slides:

It was different writing a guest post for ThoughtWorks. I often ask for feedback on my posts before publishing them, but this was much closer to having an editor. The suggestions were deeper and more serious than I usually get from friends and colleagues. I think the post turned out better for it. Also, they wrote the title and suggested the calligraphy image. I suppose I could have asked or been insistent about changing these (Kristi doesn’t understand why this picture was chosen), but I was much more honored to be asked for this than I am concerned about the title and image.

I want a conversation about what it takes to learn and master our craft, so please do comment on the post!

I will be moderating a panel over lunch, discussing the keynote address, Core Competencies given by Dr. Joyce Statz. I hope to see you there!

Aaron Swartz, a technical prodigy and activist was being prosecuted for allegedly stealing thousands of documents. A quick search will leads you to lots of details about the circumstances around Aaron’s involvement and the justness of Justice in his case.

Aaron and I first met last June and again in November, but I couldn’t say he knew who I was. Our meeting was on a bus and we were part of a rolling conversation covering the the state of business analysis at ThoughtWorks, activism, world affairs, media and branding, privacy, the security apparatus surrounding international travel, and more. In these many topics it was quickly obvious I knew about one or two issues. Aaron knew about everything else. It was intimidating, even more than usual, to be around someone who was so young and obviously better informed than I am.

As many have said, Aaron was a prodigy. And when you read enough, of his own words and those who knew him, you learn his technical abilities were only part of the story. In truth he was much more.

How many times have you wondered how something worked or why something wasn’t just a little better? Aaron wondered that, too. Aaron’s curiosity was childlike, asking why without any pretext or presumption. He understood the problem was with the systems trapping people into a course of action instead of the individuals. He worked to put together all the parts into a coherent whole and the motivation behind that whole. He believed he could work hard and make a change. He believe he, and we, could change the world. And then he worked to make it that way.

Forget about his prodigious skill. Forget about what he built so far. If you can, forget about all we have lost with his passing. Instead, dedicate yourself  to doing what Aaron did. Find a problem. Choose to understand the big picture instead of complaining. And then do something to fix it.

Aaron asked lots of questions, and then he offered himself and his talents to the solution. As we start 2013, I cannot think of a better resolution to make than to be more like Aaron.

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.”

—

One of my favorite agile principles is this,

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile teams review the software they have developed at the end of every iteration or sprint. Teams talk about and discuss the big issues standing in the way of delivering more value. Teams  make a plan and track their progress towards it. Teams consciously decide to make improvements so they will become more potent and productive. The best teams become a small-scale learning organization.

Most measurements and discussions are about developers and the development process, the rest of the work does not get the same level of attention. After thinking about the issue for awhile, I think it does make sense to measure Business Analysts, or rather what BAs do. We should measure BA outputs similar Dev outputs.

We don’t measure individual developers (as a general rule), and I don’t think we should be trying to measure individual BAs. I do think it is appropriate to measure the analysis process.

1. BAs should not be afraid to discover it typically takes N days to complete a story.
2. Teams should have insight into how many stories are In Analysis (WIP) at the same time and the average quantity.
3. We can track the analysis rate and predict if we will meet the goals (keeping the dev pipeline fed, completing the project on the same timeline as development, ?)
4. We should be able to use numbers to point to recurring patterns (a personal pet peeve: cycling from a full backlog to an empty backlog & idle developers every other iteration).
5. We should think about average story size and splitting stories as a function of analysis, not just how it impacts development estimates. (See posts by Paul James Hammant and myself elsewhere.)

We should ask questions and, based on the project and client, decide when we need to raise our hand and ask for more information or suggest a change.

In other words, I think it is possible for larger teams to evaluate the development of stories like the development of code. And we should watch the metrics around these processes in similar ways. We should watch for unexpected changes. We should make sure trend lines are steady or moving in the right direction. We should openly and honestly talk about problems in these areas during retrospectives. If we find value measuring the development process, then we can uncover value measuring the analysis process.

 —

Caveat: Through no special planning, I typically consult on enterprise projects with a team size ranging from 25 – 50 team members with 4 – 6 business analysts providing user stories for the developers. All the projects are run using agile (scrum) techniques and treat the retrospective as valuable.

I do not believe metrics are worth the effort on every project. I don’t know when / if the same measures are worthwhile on a small team (7 +/- 2). Whatever the size, when your team is high functioning, I suggest measuring less of everything.

* I withhold the right to change my mind about how easy it is to measure BA performance after I read Adriana Beal’s ebook, Measuring the Performance of Business Analysts.

—

Serendipity and the prolific @eyatzeck, points us to “How to do Agile performance reviews.”

Related posts: Measuring Requirements May Reinforce Bad Behavior and Measuring Business Analysts: Don’t KPI Me

Unfortunately, it is really easy to measure analysts poorly. Bad managers like metrics too. They are easy. They are defensible. They let you think you know what’s going on, even if they don’t provide insight or even actionable information. They can be a substitute for getting to know your people, their challenges, their needs, and their successes.

One of my international colleagues recently asked,

My client is seeking guidance on how to measure and understand the performance of the Analysts reporting to her. The phrase “Individual KPIs” kept rearing it’s head. Initial cold shiver aside, how would you answer this question?

I have already written about requirements metrics and how it can lead to bad behavior, but this question and time led me to think down a different track.

First, I am hesitant to say, “Let’s measure BAs” in any way. I realize my hesitancy is partially personal; I don’t want to be measured and then found wanting.

Second, I have never seen the objective measure do as much good as subjective measure for BA teams. I know this seems wrong, but I’ve worked with many teams trying to measure BAs and it’s very easy to find your measurements indicating the need to reward B and C players while the A player is left scratching their head. On a good team this leads to morale problems, on a bad team it leads to ever-increasing mediocracy.

My simplistic answer is to look at the teams the BAs work with. Those teams solving tougher problems and working smoothly typically have a better BA. When a team member changes teams and requests the BA to change with them, it typically means a better BA. Also, the very best BAs are known to be good by their peers and will have the respect of other BAs. Who do they turn towards or avoid?

More formally, the manager can perform 360-degree reviews. It’s not a measure of stories produced or quantity of acceptance criteria missed, but it is a measure.

Surprisingly enough, in an enterprise environment I often do not give deep consideration if the client / business partner is “happy.” I know this is sacrilege, but great BAs often push their partners and customers to do and think more. This causes more friction, often for months and maybe more than a year, despite delivering better software and solutions. On the flip side, I have seen very poor BAs do a great job listening to their partners and taking notes. The clients feels happy because they are finally being heard(!), but unfortunately this BA is acting like an overpaid stenographer and offering little value to the team. Being a good Business Analyst means understanding value much more than it means saying, “Yes, we can do that for you.” Please, reward the right kind of behavior.

Now available: Part one in the series on measuring requirements, business analysts, and part three on measuring the analysis process.

The book starts with “Section 1 – The Case Study” about the needs of fictional Squeeky Kleen. Ellen and Mary demonstrate the scope of a project and focus on key tenants within Agile, particularly engagement with stakeholders, iterative development, and learning. This approach is successful because they cover many stages of development, a host of useful techniques, and intertwine examples and tools without talking down to readers.

“Section 2 – Big Concepts” is an overview of the Discover to Deliver techniques and how the parts fit together with business partners and goals to achieve a successful product.

“Section 3 – 7 Dimensions” This section covers the seven product dimensions: User, Interface, Action, Data, Control, Environment, and Quality Attribute. While not the first model I have seen, Ellen & Mary do a great job covering all the important bases. Frankly, many projects I have been on struggled because one or more of these key areas were missed. Coming into the project and ensuring the right amount of focus on these dimensions will save your project a great deal of time and heartache.

“Section 4 – The Structured Conversation” does more than simply tell the reader how to have a conversation. Rather, this section gives advice on how to integrate the 7 Dimensions (Section 3) into productive sessions with a variety of stakeholders (Section 2) and handle the varying levels of detail appropriate for different time periods of the project lifecycle. (Section 2).

The last two sections, “Section 5 – Adapting Your Practices” and “Section 6 – Tools and Techniques” give additional information for readers to apply the central message of the book in real world situations. I did not consider this a part of the core teachings of the book, but absolutely vital if you want to move from thinking, “Cool!” to “How do I start using this on Monday?”

Stylistically, I found Discover to Deliver to be a refreshing change to traditional books, though this is a personal observation and may not resonate with every reader. The ongoing case study is detailed enough to provide context for how tools are used without being confined to a business novel and the preachiness typically accompanying them. The explanation around the tools was tools was succinct and enough to give readers a chance to see the application, without bogging us down with minutia.

The writing is clear and easy to understand. Ellen and Mary avoid all the latest buzz words and insider terms used today. The book itself used a visual “bread crumb” metaphor I found delightful. The graphics, callouts, chapter & section breaks, and even whitespace served to reinforce the message of the book rather than distract the reader. All together, the choices made this a highly approachable book and much better because of their choice.

Discover to Deliver does not pretend to cover every situation or go into deep details about how to tackle problems on Agile teams, those topics are covered in depth elsewhere. This book gives a good overview for practitioners who want to integrate bits of knowledge and take their projects and teams to the next level. I heartily recommend Ellen and Mary’s book to people who want to understand the big picture of working with Agile and turn it into a success software product.

Personal Note: I liked Ellen Gottesdiener’s Software Requirements Memory Jogger so much I used to buy the book by the dozen — I have purchased and given away 30 copies of this book. Collaborating with Mary Gorman on this Discover to Deliver, she’s done it again!

Ellen Gottesdiener and Mary Gorman, Discover to Deliver: Agile Product Planning & Analysis (EBG Consulting, 2012). 283 pp. http://www.discovertodeliver.com

—

One of the most common problems I see on Agile & Scrum teams is the stories are too large. I once had a project where a user story had over 40 acceptance criteria and took over 2 months to complete development, not including the time it took to write the story, test it, or fix what was broken. Six months later, I joined a project where most stories were estimated at 5 points, and the average 5-point story took 20+ business days to complete. This seems ridiculous to me. Stories should never be this big! Which of course begs the question, “How big should stories be?”

One of my trusted advisors, Paul Hammant has the same problem with story sizing. I prompted him to write “Call to Arms: Average Story Sizes of One Day.” The problem with his post is discusses how to fix teams when developers takes too long without stating why stories should only take one day. I finally told him, “I like what you wrote, but it’s the second half of a book. Write the first half of the book. Explain why this is important. Then I can comment on your ideas, we can get some feedback, and finally start to make a real difference.”

It’s only taken a few months, but Paul finally agreed to write the first half of his Call to Arms. In the course of badgering him, he talked me into writing a complimentary post on the same issue from a BA perspective. Paul’s new post is called Smaller Stories.

—

Here’s Paul’s thesis: 

Developers are at their best when they can complete the work at hand in about one day. 

Here’s my argument for Paul’s position:

To start, you need to understand how I view teams and getting work done. My primary reference for today’s post is from Eliyahu Goldratt’s Theory of Constraints. For those who are not familiar with his work (Shame on you! Go read The Goal.), one of the axioms in ToC is the first thing you should optimize is the area with the biggest constraint. If you spend time optimizing anything besides your biggest constraint, you are wasting your effort. For a great visual example, check out this demonstration of ToC.

Using Goldratt’s logic, I previously argued developers are the biggest constraint on a software development team. See my post Is Agile Just for Developers for more details. Taking ToC and acknowledging devs and the primary constraint, it makes sense we write stories to optimize for them. But why just one day?

I have a few reasons and they are all about the cost-benefit ratio of big versus small stories. First, despite what their non-technical friends think, developers are human and need the same thing as the rest of us. One of those things is a sense of accomplishment and appreciation. All of us need this. And we get this by overcoming obstacles and completing tasks. Finishing a story, by definition, gives a sense of accomplishment. Even when developers make fun of the story and how simple or short or easy or …, they still feel accomplishment when the story is complete. Everyone likes being able to say “I built this.” Short stories give good feelings more often than big stories.

My second point is the flip side of that, I have worked with developers with large, looming stories that take many weeks or months to finish. These folks are f-r-u-s-t-r-a-t-e-d. Even after the work is done they talk about how painful the experience was, often for more months than they worked on the story. Big stories give pain often than small stories.

I know this is touchy-feely, which many people and teams avoid, but I think it is important because it directly relates to the morale of the team. I believe Business Analysts should shepherd team morale and protect it whenever possible.

Third, larger stories are just that, bigger. And in being bigger, it is easy for Business Analysts to more likely to have missed acceptance criteria, contradictions, and implied requirements within the stories. This point isn’t about the developers, it’s about the input to the developers. Larger stories are more likely to be confusing, and this makes development much more difficult.

Fourth, the larger the story, the more developers (and other team members) have to keep in their head. There are conceptual costs to developing and maintaining mental models of the goals, business domain, code they are working in, and what they are building. Keeping large mental models for a long period of time adds extra effort to what the developer must accomplishment. Simply put, smaller stories are easier to understand. What’s easier to understand is easier to code.

Fifth, developers have maintenance costs of keeping things in their head over night, over the weekend, over the latest showing of Episode II: Attack of the Clones, over lunch, whatever.  As much as this sounds a bit humorous (and who would want to see that movie again?), it’s not. Developers, as much as they may act like machines, are not. They don’t have instant recall. In addition to building and updating the mental models above, they need to come in and figure out where they left off.

Good developers focus on, “What is the very next thing I need to do in order to make this work?” When stories are too large, then the details and variations of what must and could be coded overwhelm the very real question of what needs to be done next. Like a transition cost when you are doing too many things at one time, this cost is real and adds unnecessary effort to building solutions. Big stories make it difficult to know what needs to be done next.

Sixth, the combined effects of larger stories adds up and eventually impacts the amount of work developers can complete. When stories are too large, and the impacts of above items are all affecting the developer, it makes sense the work will take a little bit longer. The immediate impact of a single large story probably won’t hurt a project. On the other hand, the difference between a bunch of large stories and the same work broken into many small stories will add up to measurable difference. Here’s an (exaggerated?) example of what I’m talking about:

Again, I don’t have any supporting proof, but I believe a pattern of small, easier to finish stories results in work being completed a bit faster. If you work a bit faster on 10 small stories, or 40, or 600, you will save measurable time over working on fewer large stories. Small stories allow more work to get done.

Seven, it’s easier to control and change scope for value when you write smaller stories. We all know the benefit of Agile is the ability to change direction. When I deliver in smaller increments of work and show my progress to clients, I get more feedback.

Also, when I write smaller stories it is easier to put the most valuable stories first. It doesn’t happen all the time, but sometimes they say, “This is good enough for now. You can stop work on this and start working on a different feature.” The impact of discovering you don’t need to do the last week of work in a five-week story series means you avoided wasting resources. I tried to capture this in the following chart:

Jim Highsmith often talks to executives how Agile impacts value.

Rather than asking, “Did we implement all the requirements?” the question should be “Can we release this product now?” I’ve known projects that were deemed releasable with 20-30% of the originally anticipated functionality—and the customers were delighted. They got their fundamental needs met—very fast!

Writing in smaller chunks allows the team to respond to change, whether it’s a new direction or stopping the current plan. Smaller stories may reduce the amount of work needed.

What are the costs to small stories?

Part of me doesn’t like small stories; the part that has to write them. Maybe I’m wrong, but it feels like I’m doing more work when I write more stories. I cover the same amount of functionality, but writing 40 or 60% more stories feels like a lot of overhead. I believe the effort to write smaller, more independent stories is worthwhile because it benefits the developers more than it costs me. And I suffer from some of the same issues listed above, so it may not be much more effort on my part.

Also, writing smaller stories may lead you to a mess of dependencies. It is frustrating for a team to have one story block the work of other stories. It is dangerous to do too much work in the same area of the code simultaneously. Slicing work into small stories means you need to plan for how the work will be sequenced because some stories will naturally build on the result of another story.

A peer and friend, Inger Dickson, CBAP tells me this is a false argument against a good practice.

I firmly, with a flag-waving fervor, do not believe a de facto cost of small stories is dependence. Planning is important, as is sequencing, but accepting dependence as a cost of small stories goes against the INVEST model, which is the equivalent of the heart that pushes requirements through my circulatory system. This is why finding the RIGHT small stories is hard!

Lastly, writing small stories without understanding the scope may lead you down the wrong path. Writing stories in isolation from each other and the scope can give everyone a false confidence. If you do not understand the domain or approach, writing small stories can lead to big costs and add work and rework for the team. It’s similar to blazing a new trail without a compass, you think you are making good progress without understanding you are going in the wrong direction. The result is you will have to backtrack, remove the unnecessary work you added, and then start over. This is allowed in Agile and some of this is to be expected. But as a Business Analyst, I feel bad when I contribute to this by not understanding and communicating the vision properly in the first place.

Here are my conclusions:

When we write stories too big, we make our team and all the downstream recipients of our products work more. The costs for this pattern are too great. Writing one 20-day story will never get you more than 20-days of output. Writing the same functionality as 5 or 10 or 20 stories will get you the the same output, with a happier team, and quite possibly finish in less than 20 days.

My conclusion is Business Analysts can do better. When BAs write stories that are too big, we impede progress. We need to help our teams do better. We need to give our teams smaller chunks of work. As a BA, you gave an unstated promise to your team, a promise to give stories providing meaningful, valuable, deliverable work. Go out there, write smaller stories, and help your team accomplish more.

—

Notes: 

1. I cannot prove Paul is right and one-day stories are a magic bullet dev teams should be focused upon. When I talk to him about this everything makes sense to me, but we are missing empirical proof. My gut tells me that if your developers cannot finish at least two or three stories per work week, then you have a “smell” and should start troubleshooting.
2. I’m not a developer. I am very hesitant to telling a big part of my team how they should be getting their job done. I have not done the job and I do not grok all of what devs do. For me to tell them they must follow a potentially arbitrary rule is too presumptuous for me.
3. If you’re working in a Scrum or Agile or Kanban team where you break stories into tasks, then I am talking about this smaller unit. The importance here is how you deliberately size the work you are about to begin.
4. Bill Wake’s INVEST, mentioned by Inger above, is the go-to guidelines for user stories. I have found teams with larger stories are typically breaking multiple issues besides being too large or inestimable. If your team is breaking these guidelines, figure out how to fix the problem. Retrospectives are a good place to start.
5. Paul’s post has a bunch of statements about different estimating techniques and his preferences. Recent online discussions are arguing for abandoning estimates. Personally, I don’t care how you estimate. The point (no pun intended) is the size of your ‘work’, not the estimation style you use or don’t use. By the way, estimating is valuable, even if the answer are not.
6. I also think we stories should be a consistent size, but that’s a different argument and a future post.
7. I did not discuss benefits of small stories on writing, testing, or validating. I leave this for you to include within your comments below.

—-          —-          —-

A couple weeks ago I attended Gojko Adzic‘s workshop*. He started with an exercise called “Test Driven Learning.” We were asked to write down three questions we hope to have answered by the end of his workshop. After exchanging cards with other people, we became responsible for making sure our peers’ questions were answered over the following three days. I love this idea and the concept alone gave me fresh insights into training and facilitating.

Fast forward a couple weeks to last Friday, when I was asked by a team lead to facilitate their retrospective**. He wanted an outsider to lead the discussion so everyone on the small team could really contribute. After a few minutes, I agreed, but only with a caveat. I’ll only do it if I can preach about the power of retrospectives for a few minutes. I think he was amused when consenting to my plan.

I believe retrospectives are the single best thing about Agile and Scrum. The power of honestly assessing yourself and what you are doing as a team and then working to improve improve yourself, your process, and your output is without peer! Honest and mature teams transform themselves into powerhouses of capability and achievement when they sincerely work this way.

At the agreed upon time I started proclaiming the good news. I talked about the power of retrospectives. I gave the example of a team that transformed itself over the course of 14 months from being stuck to a team releasing valuable functionality every few weeks by working on small, definable tasks they pulled forward, using cards on a public wall. This team still called themselves “waterfall,” but they had added a monthly meeting where they talked about their biggest issue and found a way to work together to solve it. When their biggest issue was solved, they turned to the next issue. In the end they were a group filled with purpose and might because of retrospectives.

Another thing I mentioned was Eliyahu Goldratts‘ Theory of Constraints. Despite no one knowing about ToC and barely recalling Critical Chain, everyone quickly agreed you make the most significant progress by focusing on the biggest impediment. Tackling anything but the biggest constraint is wasting effort.

And because I had talked about making big differences, one of the categories I asked them to comment on was “What do we need to work on that will allow us to become great?” I labeled this category “GREATNESS.” Other categories were “GOOD / WELL,” for where something had gone well, and “DIDN’T LIKE,” to list minor things that were getting in the way. After briefly discussing all the cards, everyone got two votes for what they thought we should focus on to become a great team. Team members could put them on different or the same card if they wanted.

There was a clear preference for focusing in one area. I confirmed this issue would make the biggest impact on the project, the client, and our goal if it was addressed. Interestingly enough, this feedback item was not an item in the GREAT column. I was satisfied because the verbal and visual influence led everyone to focus on a big, difference-making issue instead of an easy-to-fix item, no matter what column it was found within.

At this point I talked about the power of Gojko’s Test Driven Learning and explained we were going to use this example for the retrospective. We were going to have a Test Driven Retrospective. Now that we had chosen one key item to work on, how would we prove we had accomplished our goal? In the next 20 minutes or so we clarified the goal, spent time individually writing acceptance tests to prove we were making progress, and discussed the tests. We assigned responsibility for completing the goal, and giving updates, if it was still in progress, to one individual.

As a first time exercise, some of the tests were a bit weak and needed rewording. This is to be expected because the exercise was new to everyone. Because of the weakness here, we also assigned a separate team member to work on clarifying what the test should be, better defining success.

The retrospective was just a couple days ago, and the area they chose is going to take some effort over many weeks to really bear fruit. If I get any feedback in the future, I will be sure to post an update for you to read. Without even waiting for the results, I very excited about the possibility this opens and I look forward to trying this again on my own team.

* I’m a big fan of Gojko’s book, Specification by Example and I cite it in pretty much every presentation I give. The workshop was great and lots of learning was had by all. He obviously knows his stuff. Recommended.

** The next book I’m going to start reading is The Retrospective Handbook by fellow ThoughtWorker Pat Kua. In a company of deep thinkers, he’s our expert on retrospectives. With a little luck, maybe he will comment on this idea below.

*** For another look at how a Test Driven Life can lead to increasing success, read Follow the Goal Creep over at 37signals.

“Mastering others is strength. Mastering yourself is true power.” Lao Tzu

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.

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.