Live postings from RE'09 next week!

It's one of my favorite times of year, time for the IEEE Requirements Engineering conference! RE'09 is just around the corner, starting next week in Atlanta, GA.

I'll be co-charining the Requirements Engineering Education and Training (REET'09) workshop on Monday and then attending the main conference the rest of the week, with 2 panel appearances that should prove to be interesting.

And as always, I'll be blogging LIVE from RE'09! I hope to see some of you there, find me if you are attending this year!

RML™ Requirements Model 6 - The Business Data Diagram (BDD)

Even if you don't know what it is called, we have all used one of these or something similar to it. You know, the last time you were playing the timed, trivia, board game. If Bob is Joe's uncle, Jessica is Bob's cousin, Paul is Jessica's father, and Joe is Paul's grandfather, what is Paul to Joe? Then you team stares blankly for a few seconds while someone scrambles for a pencil to start charting it out. Chances are you drew a BDD to figure out how those people were related (however poorly drawn the diagram was).

A Business Data Diagram is an essential component of the RML™ tool set. The BDD shows the relationships between entities included in a project, and the cardinalities between these entities. This diagram will look very similar to an Entity Relationship Diagram (ERD) if you are familiar with those, however it is a conceptual data model only, in other words – a BDD does not represent a physical data model (or even the fact that there is a database). We use this name as to not confuse anyone that may be familiar with ERDs, falsely implying a database design. Example included:

Why should you want to use the BDD? Because its fun to play connect the data objects, or more practically, when you have other data models. When you have other models, this is a good way to show the relationships of the data objects. Creating this with the other models also helps you make sure you aren't missing data objects. Be sure to take note of all the 1's and n's in the diagram. These are there to help you understand many-to-many/many-to-one-/one-to-one relationship types. In the example above, it is saying that each customer can have many orders associated, but each order can only relate to one customer.

Be careful to not add fields and other specific details regarding the data. This is not a database schema . That would be designing the system and we don't want to do that. That being said, a database admin could use this diagram to understand the relationships that will need to be supported in the database. If the requirements are not related to this presentation of information, it might be a good idea to skip this diagram.

Once you create this model, for each data object, you can then look at how each object is created, read, updated, deleted, copied, and moved within the system. This will help you identify additional systems that may be involved and use cases to be described. I commonly add these types of diagrams at the start of a high level view of a set of functionality so that the reader can get an idea for the data interactions before they get to the use cases, test cases, etc. that make up the meaningful requirement information.

Mission Elicitation - Phone Meetings

The site is security restricted, there are subject matter experts in other buildings, and the developers are in another country. Your mission, should you choose to accept it, is to gather the requirements for a gap analysis of your clients software implementation. Your meeting will self destruct in 3 days. You have a phone, a scribe, and a computer to complete your task, good luck.

I have a feeling that most meetings like this fail to meet their real goal, identifying the majority of gaps. A major implementation that requires gaps to be identified often have one big kickoff meeting where you were able to get all the important people to free their schedules. Of course, they couldn't be all in one place, so you have to meet over the phone. This can be disastrous. Not only does everyone over the phone lose context around presentations and discussions, but the people forget who is on either side of the phone. White boarding turns into phone charades. Scribes miss out on who said what. To-Dos are lost in the background noise.

Okay. Take a moment and breath deep. Think of pleasant things, like pre-existing documentation, SMEs that agree on the existing and future business processes, and meeting notes that make sense when you go back to read them.

Relaxed now? Alright, lets make sure we prevent as much of this as possible. There are several steps to mitigate as much trouble as possible. If at all possible, get a tablet pc for the meeting. If that is not going to happen, make sure you have access to a process mapping tool such as Visio. Secondly, make sure you have an online collaboration tool such as Go-To-Meeting, WebEx, or MS Live Meeting. If you don't have one of these tools, get a trial or find an open source (read: free) solution. The ones I mentioned would be ideal since your client will most likely have them already installed which means that there is less of a chance that the first 15 minutes of your meeting will be people discussing which button someone should have clicked instead during the install. Finally, find a scribe. If you do not have someone on your team who can help you, you might have to ask a participant to help you scribe while you try to facilitate and elicit.

Alright, you have your basic tools. First order of business, send out the meeting invite. Don't make this the standard meeting invite you see everywhere else, subject line and no description. Make sure that you include the objective of the meeting and the rough agenda. Step two, make sure everyone is introduced over the phone. Always good to go over who is in attendance and the role they are playing in the meeting. While introducing everyone, it is wise to have the meeting objective and agenda displayed on your projector and online screen sharing tool of choice. Make sure that you are located close to the phone so that you can repeat what was asked or stated and by whom.

While the meeting is going on, be sure to bring up a notepad or word doc on the screen to jot down any action items that come up. Be sure to write down who owns the task and their contact information if you do not already have it. Just having the task title isn't a nice thing to come back to and try to figure out, so add some context. Simply writing down "Get everyone's buy-in" is tempting, but please include the people involved in 'everyone and on what document/process the buy-in is needed on. At the end of each day, send out your notes to all the participants along with the list of to-dos to the owners. You might have to keep track of the to-dos and make sure their owners complete them.

When a white boarding session strikes, pull out your tablet pen or Visio program and start tossing up a copy so that everyone is involved. Much easier than describing which line connects to which box that resembles something more of a rhombus. Doing this will allow for the people over the phone to quickly understand the topic being discussed and add in their knowledge to the debate. True kudos if you are actually able to secure or setup a webcam that will allow you to broadcast the white boarding, removing the lost in translation possibilities.

These are just some basic pointers to holding elicitation meetings over the phone that can save headaches and money for your project. Do you have any phone elicitation pointers or standard operating procedures?

ProductCamp Austin is this weekend!

ProductCamp Austin is just around the corner! It's this Saturday from 9am-3:30pm. I unfortunately am out of town yet again for it, but Tony Chen will be representing Seilevel at it this summer. Hope to hear great stories back from everyone attending!

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!

Why meetings are so disruptive

Paul Graham has a great article on his blog on why meetings feel so disruptive to many of us. He partitions the world into managers and makers. Managers live their working life in 1 hour increments, so slotting a sudden meeting in is no big deal. It is just an issue of where to go. Makers live their lives in at least half day increments so that a one hour meeting can render half a day completely useless. When the two worlds collide, the makers suffer.

As Product Managers and Business analysts we have to be both. We have to have a lot of meetings where we make decisions and try to figure out what the project is going to be. Then we have to have quiet time to create the specifications. It is really difficult to switch back and forth and he offers several strategies for dealing with the context switching.

Paul mentions that a very common strategy is for makers to just ignore meeting requests. I definitely have used this strategy many times, but it is a little rude and can obviously be a bit offensive. These days I tend to put all my meetings first thing in the morning or towards the end of the day. This lets me focus on productive work with a block straight through the day. The difficulty comes with people always wanting to go out to lunch. When my productive block is from 10am to 3pm, having lunch is actually quite disruptive.

How do you handle the maker vs. manager conflict?

A Better Way to Write a Use Case: Plain English

I was talking to a colleague recently about use cases and it got me thinking about my evolution as a use-case-writer. I used to do formal use cases exclusively – where they very clearly denoted system and user steps (whether in one list or 2 columns), preconditions, triggers, Postconditions, etc. etc. etc.

After years of writing and teaching about formal use cases, I have to confess, I rarely write them now. Sometimes I still teach about them, I think it’s important to know how to write good ones. But the reality is that as we move towards shorter-iterations on our projects, the less formal we need them to be in the use case itself. What I’m finding works really well are these use cases written more like user stories. They may still have a linear set of steps, but the big difference is they are written in a more readable language of plain English with slightly less structure.

I’m oversimplifying but to make my point, instead of:

1. System displays shipping fields

2. User enters shipping info

3. System displays payment options

4. User enters payment options

I could simply say:

User enters shipping and then enters payment information.

I’ve conveyed the same information without stating the literally obvious points. You have to be careful here though, don’t assume the obvious incorrectly! Now, before you agile non-documenters jump up and down and say “I told you so!”, I want to be clear – you still need to write something down. This is the part that many projects neglect to tackle is the next level of detail. You still need to capture specific functional requirements for this use case/user story – there are our typical RML™ – with people, systems, data models to be created that describe those requirements, So I use the user stories, just like I used a formal use case – stepping through each “step” and determining what details need to be specified for building the software. Oh and one more thing, I do still use preconditions, triggers, and actors in the header – just makes it cleaner to call those out up top.