The Seilevel 2009 Software Requirements Holiday Medley

It's that time of year we all look so forward to, when we get to wish our colleagues around the requirements world a bit of SeiCheer with our holiday medley of songs. And worry not, if the 2009 collection isn't enough for you, you can go back in history and read our 2008 songs, 2007 songs, and our original 2006 songs!

Without further ado, sing along with us....

We wish you a Merry Release
We wish you a Merry Release
We wish you a Merry Release
We wish you a Merry Release and we hope it is near.
Requirements we bring to you and the team
Requirements for Release and we hope it is near.

Oh, bring us a new prototype
Oh, bring us a new prototype
Oh, bring us a new prototype and we'll love it, no fear

We won't go until we see it
We won't go until we see it
We won't go until we see it, so send the link here

We wish you a Merry Release
We wish you a Merry Release
We wish you a Merry Release and we hope it is near!

Oh Project SME
Oh Project SME! O Project SME!
Thy needs are so unchanging
O Project SME! O Project SME!
Thy needs are so unchanging
Not only at start are they clear,
But also when 'tis launch is near.
O Project SME! O Project SME!
Thy needs are so unchanging!

O Project SME! O Project SME!
Much time thou can'st give me
O Project SME! O Project SME!
Much time thou can'st give me
How often has the Project SME
Afforded us the scope for free!
O Project SME! O Project SME!
Much time thou can'st give me.

Rockin' Around the Requirements
Rocking around the Requirements
at the discovery workshop
Feature lists hung where you can see
Ev'ry executive tries to stop

You will get a validated feeling
When you hear voices saying
"Let's be jolly; Deck the walls with flows, oh golly!"

Rocking around the Requirements
Have a happy launch day
Everyone's drawing merrily
In a new best practice way

Rocking around the Requirements
Let the user stories sing
Later we'll write some data flows
and we'll do some modeling

You will get a validated feeling
When you hear voices saying
"Let's be jolly; Deck the walls with flows, oh golly"

Rocking around the Requirements
Have a happy launch day
Everyone's drawing merrily
In a new best practiced way

Rudolph the Brown-Nosing BA
Rudolph the brown-nosing BA
had a huge need to know.
And those who ever met him,
hoped they'd just let him go

All of the other BAs
used to scowl and call him names.
They never let poor Rudolph
join in any BA games.

Then one foggy release eve
VP came to say:
"Rudolph you are so very bright,
won't you guide my launch tonight?"

Then all the BAs loved him
as they shouted out with glee,
Rudolph the brown-nosing BA,
make our sponsors so happy!

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!

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!

REET’09 Went Off Without a Hitch!

Monday was the Requirements Engineering Education and Training (REET) workshop that I co-chaired with Ljerka Beus-Dukic. I’m always nervous about how these things will go – there are so many unknowns with the environment, the presentations, and the timing. However, I’m absolutely thrilled with the end result! We had 6 papers presented and it varies from a normal conference in that we had big blocks of discussion to really dive into some of the commonly shared issues in this field.

We had a lengthy discussion mid-afternoon around how do you really teach anything about requirements to students in a semester long class (or less!) and where does requirements training fit in the overall teaching of the software lifecycle at a university level. The thought is that most people learning about requirements in industry aren’t brand new to software development, they already understand a bit about coding and verification, so they understand the value and context for requirements. Yet trying to teach it to a freshman class would leave the students thinking “why do I need to know this?”

Another key point that is important at all levels is repetition in the lessons they receive. It came up again in the context of academia, where they may teach it to freshmen, and then they need to re-teach it throughout in other classes. This isn’t specific to requirements certainly, just a basic principle of good training.

We also talked quite a bit about how you assess the students in and after training. This is a long standing BIG problem across academia and industry. One issue with assessing whether any behaviors changed in an academic environment is that you teach it and they may use it on a project, but then you never see the students again. One participant actually tries to talk to industry contacts who hire the students to see if they see better results from his students. In industry, it’s very hard to isolate whether results are attributed to training. We can look for modified behavior, but this requires a dedicated resource to do so. I’ll probably talk about this more in a day or so, since we have a panel related to this on Thursday!

We then ended the day with 3 different sets of training activities presented with the intent on getting any participant feedback on the activities, but also leaving the workshop participants with the opportunity to take the exercises back and reuse them. At the very end, we played one of our Seilevel training games: Bet on Yourself Pictionary – it was fun because I was working with a group of people who are already familiar with requirements models in some form and so they could play our game – which basically enlists 2 “students” to act as analysts drawing requirements models for a specified scenario, trying to get the rest of the class to elicit the requirements from them. Oh and they had to do all of this without speaking. It was great fun and if nothing else, a lively way to end the day!

Project Pulse - Project Velocity

Or we could call it 'Project Speed' if you are a big fan of movies where objects that move too slow are reprimanded with high explosives. Either way, we are talking about a project management metric that is very helpful in identifying problems and adjusting milestones.

What you will need:

o A Project

o A team or yourself

o A task list

o Estimated hours

o A record keeping system (such as excel or crayons and paper)

What you will be doing to monitor a project's or individual's velocity is assigning an estimated task time to all the new tasks that may show up on your project. So first make sure that you have a list of all your known tasks and that you and/or your team has given a best estimate for time to complete them. Once this is done, go ahead and add up the total estimated hours and set that aside. For now, lets say that you came up with 100 hours of tasks.

Go ahead and work on the project for the day. Either at the end of the day or before working the next day, get the sum of project hours remaining and record that again. Lets say that the first five days yielded 104, 115, 103, 93, and 80 with two people working on the project.

In the perfect world you would assume that two people working a project would net you 16 task hours completed a day. As we all know, this will not happen or we would all be spending additional hours at work for meetings, side tasks, waiting for feedback, dealing with IT issues, delegating work, etcetera just to get the 8 hours of task work completed (wait a minute...) So, now that we have the remaining estimated work for the week, we can figure out the velocity daily or the average. Starting with the daily, the team seemed to have the following results; -4, -11, 12, 10, 13. Taking the average of those hours will give you 2 hours/day as your current 5 day velocity.

What does it mean though? This is where you will have to take a closer look at the data or have a meeting with the team. In this particular case, we gained hours on the project time during the first two days. After that we seemed to get what could be considered normal results. Possible causes of the velocity could be from any of the following: incorrectly estimated task hours, discovery of new tasks during project ramp up, poorly performing team, obstacles are preventing task work from being completed, failure to properly update tasks with remaining hours, or shared resources being used on the project. Some of those same reasons could also be the cause of a faster than expected project velocity. Alternatively, unique causes of a faster velocity could include the rapid closing of tasks toward the end of a project when estimations are not as conservative, resources performing above expectations or putting in additional time, or removal of tasks from scope.

Once you understand why your Project Velocity is what it is, you can now reforecast when your project milestones will occur based on the current performance. It will also help you identify if any of the issues mentioned in the prior paragraph are occurring so that you can fix them or congratulate the team for the good work. Keep in mind that you should see slower rates at the start of a project, where new tasks are being discovered and people are being conservative about how much time is required to complete tasks. Faster rates should occur towards the end of the project where tasks are being knocked out of scope or finished with better efficiency.

Try using this data for a project dashboard that shows current data, historical trends, and project goals! Bonus points if you work in a speeding bus!

What is the Value of that Feature?

Alright. You've just identified the features that your client doesn't need going forward, the ones they can hold off on for now, and the ones that have to be implemented with the project. How did you come to that conclusion?

Were all the different group's champions in a room with you giving the thumbs up or down? Did the project funder push their features through? Maybe the cries of anguish from users as you held a feature over the out of scope bucket let you gauge how much it was needed. Are any of those a sound business case for the need of a feature?

Depending on the grandeur of your project, maybe it is. My bets are that it isn't enough. To really know what should or should not be implemented, every feature should be tied to a business objective. At the highest level you should have something along the lines of increase sales and decrease costs. From these you can have supporting objectives such as training sales, increasing client meetings, reducing cost of proposals, etc.

So did the project really need the feature to search for client information? I would imagine that kind of feature would be tied to an objective to allow for easier access to operational data, which ties to another objective to reduce costs of supporting client request. Given that, you should have a list of measurable KPIs (key performance indicators) for these objectives. This case might have a measure of the number of client requests for data per day and how long it takes to resolve the request with and without the search capability.

Now you will have to compare how strongly this feature affects the objective to reduce costs of supporting client requests. If there are a few other objectives that tie into this one, then you might imagine that the easier access to operational data could have a 20% correlation to the parent objective. From there you can take your current costs, multiply it by how important reducing costs of supporting client requests is and then multiply that against how important easier access to client data is.

So for example, let us say that our costs are $25,000. Turns out that reducing the costs of supporting client requests objectives is 30% of that cost. Now all the sub objectives are worth some part of $7,500. We said that the objective to provide easier access to client information was contributing 20% to its parent objective. This means that it is worth $1,500 of your costs.

Now you know that not having the feature costs you $1,500. You can estimate the implementation costs of the feature as well. If the implementation is higher, then arguably the feature should not be built. If the implementation cost is less than the value of having it, then you may want to build it, but at that point, you should compare the value of all the features in case you cannot build them all – choosing the ones with the largest value.

How to Select Software Requirements Training (It's not just about the BABOK)

So it’s time for your organization to select requirements training for your business analysts, product managers, project managers, even developers. Here are some suggestions on what to look for!

The obvious things to look for:

• Course Agenda – make sure the agenda is published and the topics seem relevant to your group. For example, if you do not use RUP, do not select a RUP-based class. If your team is good at the basics, consider a more advanced class, for example focusing on elicitation.


• Training Costs – these are relatively consistent across courses, but typically you can expect to pay anywhere from 600-1500 per day per student.


• Time Commitment – make sure you sign up for a course you are willing to commit to. Typically industry courses are run in full or half day increments. Make sure your people know it’s a priority to attend once you’ve signed up. Also, I prefer courses that are done in smaller increments, for example a series of 4 classes at 2 hours each, because the students can take time to think about and practice the concepts between classes. This resembles the teaching method used in universities, but it is very hard to find in industry.

The less obvious but more important:

• An Engaging Experience – the materials used during course must be engaging, as to not bore the students to sleep. As a rule of thumb, most learning happens in practice not lecture, so look for a course that has at least 50% of the time doing practice exercises.


• Competent Instructors – be sure that the instructors will be interesting to listen to. This may be tough to evaluate, but you could try calling them ahead of time. In addition, they need to be credible. My personal favorite is to find instructors who are also practitioners, having actually done the thing they are teaching. They will use more real-life stories in their teaching, which help put the lecture in context.


• Your Expectations - Be realistic yourself about what you will get out of the training and what you won’t. Referring back to the Kirkpatrick model, most training only measures levels 1 and 2, satisfaction and immediate recall of the material respectively. If you are looking for level 3 and 4, behavior change and impact to the organization, then recognize that most training alone will not give you those, and certainly is not likely to measure that they did happen. Typically mentoring in addition to or instead of training will help you get to level 3 and 4 in the organization.

Sadly, I have seen disappointed students coming out of all kinds of training experiences, and typically it is because their expectations were wrong going in.