Delivering Business Value with Agile Approaches to Requirements, continued

This post is a continuation of a previous post found here.

Changes Dave believes are coming with respect to agile-run projects and my own commentary on these:

• Requirements engineers make decisions, they are not just documenters. Expect to see that product owners are the BAs. They will less often be called systems analysts, and more often called product owners. A few years ago, we shifted from calling our requirements team members “Business Analysts” and started calling them “Product Managers” because that’s really what they have to do – own the product, even if it’s just an internal IT system.


• BAs/Product Owners will be empowered to make decisions and not just sit around waiting on sign-off. They must be experts in the business. They must work with development, not just document for them. Once they do this, they can start to make very smart decisions about what should or should not make it in the product.


• Agile is not a fad, even NASA is doing it. That said, we will see variations on agile as it grows and evolves.


• The development team can add value about requirements, so collaborate with them. They don’t all just want to gold-plate scope or push back on what’s in or out – they love to build products, so use that to your advantage.


• The business is not always right, so you still need to ask questions. BAs/Product Owners must push back when something doesn’t make sense.


• Agile is actually seen to increase the value of requirements – just make them more solution focused, and not just about doing lots of documentation.

And finally, Dave made my favorite quote from RE’09: The difference between UML 1 and UML 3 is that we moved the stick hands from being straight out to angled downwards. He can make jokes like this since he actually worked on it!

Delivering Business Value with Agile Approaches to Requirements

I attended a keynote at RE’09 in Atlanta that I wanted to go back and post a summary of and my thoughts on. And just to be completely honest, this is a rarity. For whatever reason, I really tend not to get much value out of keynote talks – either they are too technical, the speaker isn’t great at well, speaking, or they are so out there I cannot engage in it. Today was different though, it was captivating for me. This one was given by Dave West of Forrester Research. The talk was titled “Developing Business Value with Agile Approaches to Requirements”.


To be fair, he had my attention at the first slide – it was a picture of a dog doing agility. When I talk about agile, I use such a picture too since I personally do agility with my dog! Anyway, the content of the talk proved to be interesting. Some will say it wasn’t anything new. Others will argue with what he said. But for me, his ideas were very tightly aligned with our experiences and ideas about agile and requirements so I like that it built on what I already knew and gave me new ideas to think about. The great thing is he has a much larger pool of resources to survey and confirm his ideas. Here are a few of the points of interest.


He talked to what is being adopted with respect to agile and among those things: Agile itself is being adopted. Scrum practices are as well. He also sees engineering practices such as early testing, integrated builds, and re-factoring. But most of note, he is most commonly seeing a hybrid of approaches– more of an agile than an Agile approach. I think this is relevant as I hear company after company say “agile didn’t work for us”. In reality for many companies it probably doesn’t in its purest of form. Or perhaps it requires trying it more than once, learning from mistakes (do we really think Waterfall worked the first time either?!?!).


Some really positive things he believes we are seeing now include frequent delivery, increased business involvement with more collaboration, and changes in team organization towards smaller teams and more of a team focus in general. His thought on when agile is best used: Complex projects where there are problems to be solved and the solution is unknown.


Dave spoke to the common friction points between traditional requirements approaches and agile:

• Delivers requirements vs collaboration on the product
• Where in the process you engage vs. iterative
• Requirements that are out of date, long/hard to read, solution focused, take way too long vs. collaborative and timely requirements

Some of the issues that you must be careful about with agile: Often the customer has no time because they are doing their day-job (the one you are trying to help in some way with software!). There are often many customers to involve in the requirements efforts, not just one or two to quickly jot down stories with. The customers are often distributed so you have to bake in time to work with all of them alone and together. Agile is reliant on good communication but stereotypically, developers don’t communicate well. We cannot ignore analysis - processes require analysis and solutions require thought - so take time to do these.


I will continue this post in a day or so with thoughts on changes that Dave thinks we are starting to see, as well as my personal thoughts on his thoughts!

An example of Blueprint in Use on an Agile Project

I attended a talk by folks from BluePrint and Lexis Nexis at BAWorld on Tuesday at BAWorld: Boston called "Requirements Definition for Agile Projects". The first bit of the talk was just an intro to agile and why it is useful on the projects. The part that I found most interesting was from Kathleen McGoey who owned business analysis on lawyers.com - she effectively gave a verbal case study of their team using agile and Blueprint to deploy this site. This was refreshing because she was brutally honest about the state of their organization 2 years ago, some of her dislikes about other tools, and their experiences with agile not going well. However, she also then talked about how their culture is changing now and what is working really well. This talk was great because it was effectively a great sales-pitch for Blueprint, but it was given by an actual user....and you could tell she was being honest about it.

Blueprint is meant to be a BA tool. They are closely partnered with HP and it integrates to Quality Center for QA use as well. From a quick glance of things she mentioned or showed, it looks like it allows you to manage the list of features in a backlog, low-fidelity wireframes, diagrams that look a lot like visio, export to Word, and import from Excel. We are still using Borland's Caliber happily, but I'm obviously always looking at all the tools on the market to see what people are really liking and/or disliking, what new features are coming about, what's easy to use, etc.

A bit about the lawyers.com project - they were executing 3-12 week sprints and the requirements definition is about 2 weeks ahead of sprint cycles. She made a very wise comment - templates and processes are good to an end, but only if the BA knows what they are doing already. She spoke of junior analysts who are given templates and when you look at their work products you think “Oh no! what are you doing!”. I think we’ve all probably seen that. You can use the templates and processes to train them, but they aren’t enough, but they aren’t enough.

Another neat thing she briefly mentioned was the idea of doing something like pair-programming, but where the pair consists of a BA and a user experience expert – so together they are designing the wireframes. I haven’t tried it, typically our individuals are doing both activities.

Anyway, it was good to hear the “how it works” story from Lexis Nexis. And I haven't used Blueprint myself, but I am certainly interested to hear others' experiences with the tool, so please comment if you have used it.

BluePrint Tool

I attended a talk by folks from BluePrint and LexisNexis at BAWorld on Tuesday. The first bit of the talk was just an intro to agile and why it is useful on the projects. The part that I found most interesting was from someone who owned business analysis on lawyers.com - she effectively gave a verbal case study of their team using agile and BluePrint to deploy this site. This was refreshing because she was brutally honest about the state of their organization 2 years ago, some of her dislikes about other tools, and their experiences with agile not going well. However, she also then talked about how their culture is changing now and what is working really well. This talk was great because it was effectively a great sales-pitch for BluePrint, but it was given by an actual user....and you could tell she was being honest about it.

BluePrint is meant to be a BA tool. They are closely partnered with HP and it integrates to Quality Center for QA use as well. From a quick glance of things she mentioned or showed, it looks like it allows you to manage the list of features in a backlog, low-fidelity wireframes, diagrams that look a lot like visio, export to Word, and import from Excel. We are still using Borland's Caliber happily, but I'm obviously always looking at all the tools on the market to see what people are really liking and/or disliking, what new features are coming about, what's easy to use, etc.

A bit about the lawyers.com project - they were executing 3-12 week sprints and the requirements definition is about 2 weeks ahead of sprint cycles. She made a very wise comment - templates and processes

I haven't used BluePrint myself, but I am certainly interested to hear others' experiences with the tool, so please comment if you have used it.

Creating BA Competency

As part of our Live from BAWorld: Boston series, I just heard a talk from Karen McKay at Doreen Evans Associates (DEA). She discussed building a BA competency in your organization. Her talk was focused on the high-level need for such a model and what the components of it are. I think a next level of discussion that would be interesting is tactics you could use to create one yourself - which specific tools and tactics work.

At DEA, they use a model that is very similar to the CMM, with five levels of competency: initial, repeatable, defined, managed, optimized and have helped build this at a handful of organizations. We do something similar to build BA maturity in organizations, but I haven't actually seen it laid out next to the CMM model quite like this. At the requirements process level, they use requirements models which I applaud - context diagrams, org charts, use cases, process flows, DFDs, etc. This talk further validated what I'm seeing in industry - alas, models are really the current state now. So if you write your requirements in plain old text, I fear that is really seen as out-of-date "technology" and you need to look at visualization techniques.

Something interesting that she did with her slides was to describe parts of their competency models using requirements models. For example, there is a swimlane diagram to show the BA role - clearly showing how BA activities relate to IT and PM functions. I haven't done much of this recently and think it's a great idea that I will use.

Anyway, this is a topic that I'm definitely interested in as we try to help customers build their competency around requirements as well. It seems like organizations are really recognizing the value of BAs now!

Using Use Cases To Create Test Cases

As part of my "Live from BAWorld: Boston" series, I attended a talk Monday by Matthew Leach of Doreen Evan Associates called "Leveraging Multi-Level Use Cases for Testing and Other Ways to Obtain Greater ROI on your Business Analysis Investment".

His talk went into great depth about how you could use use cases on your project in multiple ways, looking at different levels of detail in use cases. He quoted a study from VokeStream that indicated 76% of people surveyed manually build test cases still.

This is the one point I also wanted to emphasize the importance of: re-use your use cases to generate test cases, particularly user acceptance test scripts (UAT scripts). At some level this seems obvious to me, but I don't think it is all that obvious after all based on the above study, Matthew's experiences, and my personal ones as well! On a recent project I worked on, the business came to us to talk about how awful the integration and unit test cases were - that they just would not work for UAT. My immediate thought was "well of course not, those aren't meant for UAT". Apparently QA had told them to write their UAT scripts from these test cases. That's almost as challenging as writing them from code! So we walked them through how we could take the use cases we had written (which the existing test cases were generated from) and easily translate those into UAT scripts.

If you think of your use case having a happy path and alternative paths, you would want to blow out each of those paths into at least 1 test case each, by adding concrete data to the use case. So for example, if there is a step for the user to input "shipping information", then in the UAT script, you would want to supply actual shipping information including a specific name and address that would be in the test data set. It's important during UAT to also test the alternate and exception paths - to ensure the not-so-happy path and errors are handled to the business' satisfaction. That said, it's also unrealistic to think your users have time to test all possible paths. To mitigate this, I have two suggestions.

1. Pick the most important UAT scripts to test. You have to decide what "important" is, but it would be wise to look at the use cases that add the most business value and/or are most frequently used.
2. Use your BAs during UAT - particularly for the less important test cases that the users can't it.

BAs Need to Think Quietly

Also at BAWorld: Boston, Monday I heard Barbara Carkenoard talk about "ROI? Measuring the Real Value of Business Analysis" and her learning objectives were:

• Learn to talk about the specific value of a strong business analysis discipline
• Consider business analysis metrics for use in your organization
• Understand why a financial ROI is not normally calculated for business analysis

Some of the key points of interest for me were these, with my own commentary:

Business analysts should be involved in creating the business case. Most projects don't bring them in until the project is already decided upon. But business analysts inherently are good at analysis and can really think through whether a project even makes sense.

Business analysts need to figure out how to block out big chunks of time to think quietly. Analysis requires thinking...so let them think!

An interesting discussion took place around cultural differences between countries and how it relates to the use of process or lack of. This came out of a question about why organizations try to short-cut business analysis on the projects. And Barbara proposed that the US culture is one of "hurry up, slam it in, we'll fix it later" whereas a lot of other countries (she named Canada and the UK) are more likely to follow a process to get it done right. I laughed because just last week I had an executive say "It's okay if we don't get all the requirements defined, we'll just log everything not yet written down as defects and fix them in QA"...and he was very serious about it.

Live from BAWorld Boston

This week I find myself at Project Summit & BAWorld: Boston for about a day and a half.

This morning I presented our talk, "If you Build It, Will They Use It? Leveraging Business Objectives to Deliver Successful Projects". One thing I like about the BAWorld symposiums is that they make the slides available electronically to everyone, they are reviewed by a committee before you can present them, and they insist that the speakers provide learning objectives so you know what you are getting. So to that point, here are the learning objectives for my discussion:

• Understand how Business Objectives are vital to businesses
• Understand how to elicit and write good Business Objectives
• Understand how to use Business Objectives to assess measurable value of individual features

I had a blast with the audience here - great participation in some of my games (yes, we do them in presentations, not just our training classes!).

If you haven't been to one of these conferences, I recommend it if you are a practitioner doing Business Analysis, Requirements Engineering, or Product Management. Everyone else here is also practicing the "art" of BA and looking for new tips and techniques to take back to their organizations.

Anyway, I attended a few other talks of interest today that I'll blog about shortly!

Software Requirements Soundtrack

I am going to take it a little off the beaten path for this post and ask about some 'non-functional' work requirements you have. So I was wondering what you all like to do when you have to stay focused? Do you listen to classical? Work remotely from a coffee shop or home? Put a big frown face on your office whiteboard warning intruders to stay away?


I personally have my ear buds on hand wherever I go to work. They help me whenever I need to keep my head down and not be distracted. Granted, the slow and methodical opening of 20 or so metal blinds with 5 or 6 pulls each isn't easily drown out.



I favor listening to either Classical or Spanish Guitar music for working at the client site or office. Not for the 'classical makes your baby smart' argument. I do find that these two types of music help instill a calm demeanor and have enough movement in the music to help you get into a pattern. The ear buds themselves do the work of drowning out the background conversations regarding the explosion of a stress ball and its contents upon the ceiling.


Alternatively. When I have a large quantity of documents to review or large processes/maps to create, I favor my home office. I can't help but need a great chair, huge monitor, and fast internet for researching in these cases. Granted my music changes to more modern content to keep the mind from burning out on the same tasks. But in either case, I welcome some interruption since I am not the only one with deadlines.



Do you have different styles of work when it is focus time? Let us know, we would love to hear back from you. Perhaps you had a moment that you really wished you had some way to stay focused.