Well, gentle blog followers … is there a more technical name for that?  Please contact me and let me know if there is (inquiring minds and all).  As I was saying gentle blog followers, if you have been following along, you now have a pretty good high-level definition of a Community of Practice and a Center of Practice.   A Center of Competency (or Competency Center) is about measuring and managing performance.  This generally includes: people, industry standards used, internal standards used and how competent people are in those standards.  Okay, on the surface that sounds easy, right?  Well, not when you are dealing directly with the human component.  People are naturally afraid of the measurement process and change in general even if it is helpful.  However, a Center of Competency (with the right model) done right will help to eliminate subjective measures, favoritism and other unwanted behaviors and practices that really do not help the success of our people or processes.

So, let’s look at a slightly deeper view of what a Center of Competency could entail.  It looks at the skills of the person who is performing a given task or technique.  It looks at the practitioner’s knowledgebase and tries to determine their proficiency in their discipline.  It looks at self assessments, overall maturity assessments (Business Analyst and Business Analysis).  It defines roles.  It looks at how to manage job expectations.   It looks at how managers and peers provide feedback (not criticism but honest to goodness, real and useful feedback).  It could include a mentoring and coaching program.  Which I need to point out there is a BIG difference between the two (sounds like a future blog coming your way on that topic).   My personal favorite is that it should tie one’s performance to pay appropriately.  It identifies training needs and it could include much more depending on the company culture and needs. 

Well I think you now get why this is not exactly easy.  Additionally, there is a large Human Resources component here which makes the challenge even more exciting!  The Competency Center with the appropriate model and approach will show people how to get from point A to point B – a clear path to keeping practitioners engaged in their careers.  It will help management understand the full spectrum level of support needed and also to reassure them of why they are making a good investment in their people and processes.  It could just be me, but I seem to think that this is just the right thing to do for people.  What do you think?

BACOE Blogisode #4: The BA Competency Center – Do you need one? OR… Competent is as Competent does. was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

UC Diagram-Training Example

Since most people refer to these as use cases, that’s the name I’ll use. They are a great way to elicit, analyze, and model interaction requirements. Plus, they help generate related requirements for interfaces, data, process, and business rules.

I gave a use case training class last week, so it’s fresh in my mind. It also influenced me to put this explanation in question and answer form.

Q. What is a use case?

Use cases and scenarios describe functionality that describes how actors interact with a system. The system could theoretically be anything, but use cases most commonly are used with online or web applications. The term “use case” is often a short version of “use case narrative” or “use case flow of events” and is shown as an oval in a use case diagram as in the example above. They are written as text and divided into primary, alternate, and exception scenarios.

Q. What is an actor?

Actors interact directly with a system, and can be humans, systems, or event/time triggers. In a banking system, an actor might be a teller who enters banking transactions and a Customer Information System that supplies and maintains customer data. They are shown outside the use case diagram as stick figures or using an icon like in the example above.

Q. What are associations?

These show which use cases an actor can initiate and which actors a use case can access. The line between an actor and its associated use cases depict the associations. The BABOK® uses the term association for this concept, and another common term for this is interface.

Q. What is a scenario?

A scenario is one path or flow through a use case. Typically a use case has a primary scenario, one or more alternate scenarios, and possibly exception scenarios. For example, a bank transaction might be completed using a customer’s account number (primary path), using the Customer Information system to look up the account number (alternate), or be cancelled (perhaps due to not locating the account number). One of my favorite ways to summarize use cases to my students is they are a collection of related scenarios in the accomplishment of a goal.

Q. What is a use case model and what are its components?

A use case model contains the use case diagram and the text scenarios and flows.

Q. What does the BABOK view as the specialized relationships in use cases?

There are two specialized use case relationships described in the BABOK. There is a third (and useful) relationship that the BABOK does not describe, but I listed it below for completeness.

1. Extend- documents the place in a use case to add future extended functionality, like an alternate path in a separate use case. “Search Name Phonetically” is an example below of an extend relationship.
2. Include – provides access to shared functionality in a separate use case. The common functionality is housed in a separate use case and is “included” by one or more use cases that share the same functionality. In the banking example, looking up customers by name is a common function that would likely be in an included use case, such as “Locate Customer” below.
3. Generalization –separates the general interaction steps from specific detailed steps for use cases that have a Parent-Child sub-type structure. In the following example, there is a generic Transaction entity with a use case of “Make Transaction” that has sub-use cases of “Make Deposit,” “Make Withdrawal,” and “Make Loan Payment.” Actors can be generalized as well. (This is an accepted and useful relationship that was included in BABOK® version 1.6. I would like to see it added back to BABOK® version 3.)

To sum up, Use Cases are an important and widely used technique for capturing interaction requirements. They provide a structured means to uncover many hidden and detailed requirements, and they can lead to related interface and data requirements. Because of their importance in the industry, expect to be tested on them in the CBAP exam.

LEARN MORE: For more information, read our article on Use Cases called Demystifying Use Case Modeling. It requires a simple one-time registration for you to access it. Once registered, you can read dozens of other interesting article on business analysis and project management. A good, basic book on Use Cases I recommend is called Applying Use Cases, Second Edition, by Geri Schneider and Jason Winters, ISBN 0-201-30891-5. We also teach a practical, concise training course on Use Case Modeling to learn this technique in-depth.

Scenarios and Use Cases – Useful Techniques was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

This month, inspired by a debate on Agile vs. Waterfall, presented by the Phoenix chapter of IIBA, I want to compare Waterfall to Scrum in a variety of different ways. As I listened to the two sides during the debate, I was amazed at the number of the similarities, as well as the importance of the subtle differences. This month’s blog will explore both the similarities and differences. Before I begin, I want to stress the point that neither one is a methodology. Neither is prescriptive. Waterfall is an approach. Scrum is a framework, part of the myriad Agile methods. Both allow for the use of a variety of techniques. To be effective, both require an appropriate amount of rigor, although we acknowledge that both approaches have been implemented in a wide variety of ways. For the discussion below, we’ll assume the appropriate level of rigor for the project at hand.

Similarities

There are many ways in which these two approaches are similar. Both:

1. Have processes to request, approve  and  prioritize  changes. Both  put focus for the approval and prioritization on the Business (product owner/sponsor/SMEs).
2. Stress the importance of communications.
3. Allow for more or less rigor as appropriate.
4. Find communications easier when the teams are collocated. 
5. Both face more challenges with virtual teams.
6. Have processes to manage the scope.
7. Estimate the work involved in business analysis whether phase (s), releases, iterations/sprints.

Differences

Many of the differences lie in how these processes are implanted. To understand the vast differences in implementation, we need to understand that many organizations have their own methodologies, so their processes for completing business analysis vary extensively. Also, many organizations use hybrids or “best of “breed” implementations. With that in mind, let’s examine some differences between Waterfall and Agile.

Intricate, large projects

On large, intricate projects with many business and technical interfaces and impacts, with a variety of cross-functional SMEs or with many compliance regulations, there are advantages to the Waterfall approach. While these projects can also be implemented using Scrum, it is harder when there are project dependencies.

• Coding and testing. On the large projects I managed, we were always touching programs and test data that other teams needed and vice versa. It seems to me that following a detailed  plan places less stress on all the teams. Even when slippage occurs or the team completes programs earlier than anticipated, following the plan and communicating variances in a more formal and proactive way is helpful to all the teams involved. Again, it can be done using Scrum of Scrums or other processes, but I have found that following a plan is a stress-reliever.
• Incorporating changes. Again, when there are approved changes and there are significant project dependencies, it can be helpful to change the plan, so that a schedule for completing these changes can be determined and communicated to everyone impacted by the change. This is particularly true when the approved changes have significant impacts and can cause changes not only to work completed by the team, but by work already completed and tested by other teams.

The winner: Waterfall!

Defining requirements when they are highly volatile

Waterfall projects have approval points, often called toll or stage gates. When requirements are unstable, business analysis can seem to take forever and the sponsor may get frustrated with what appears to be analysis paralysis. I once had a sponsor tell me that he had never seen analysis take so long, but  was surprised and delighted that the project get done so quickly once we had the requirements. Thoroughness in requirements definitely paid off. However, there was significant frustration as the churn was happening.

Scrum projects have the wherewithal to handle this kind of churn better in my opinion. User stories that are pretty well understood are closer to the top of the product backlog and are ready for inclusion in upcoming sprint(s) than “epics” that are less understood.

The winner: Scrum!

Managing scope and changes

On Waterfall projects schedule, cost, and scope baselines are established (as well as others). These become project constraints. When changes are approved and prioritized by the Business, the sponsor, often upon the recommendation of the project manager, needs to decide which of the baselines will change. I have talked to many Scrum proponents who argue that Agile projects expect change, but Waterfall projects do not. This assertion is simply not true. I have yet to be on or hear of a Waterfall project that did not expect changes. Having said that, modifying the schedule, particularly when it involves changing dependencies, can be cumbersome and frustrating.

I think managing scope on Scrum projects is easier in many respects, most of which relate to the fact that having small sprints helps the framework accommodate changes with far less pain. In addition, I have seen more consistency in the way changes are requested, approved, and prioritized on Scrum projects. 

The winner: Scrum!

I could go on with this comparison, but my little blog is turning into a full-fledged article, so I’ll simply list out areas where I think Waterfall wins and address them in more detail in future blogs.

Waterfall wins in these areas:

• Effectively using the role of the BA to define requirements completely using a variety of elicitation and modeling techniques. Although Scrum is catching up, it still lags behind.
• Defining the business need and business case. Most of the visioning I have seen on Scrum projects has tended to be superficial. Again, this may be due to the way I have seen it implemented.
• Getting from the “as-is” to the “to-be.” Ensuring that the solution in general and software in particular supports business processes or if not, that the business is ready for the change with such things as new processes, training, the required sales, marketing and support resources, etc.

Of course Scrum wins in some other areas, too…

Scrum vs. Waterfall: The Fight Continues was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

Finally, Mrs. Bear comes along and asks “If you had a mommy, what would she do?”  Choco explains that his mommy would give him hugs and kisses, sing and dance with him to cheer him up, etc.  When Mrs. Bear suggests that she could be his mommy, he happily goes home with Mrs. Bear and meets her other children, his new brothers and sisters: Ally (a baby alligator), Hippy (a baby hippo), and piggy (a baby piggy).  (Lemme tell ya – Hallmark commercials have nothing on this book when it comes to bringing me to tears.) 

For us adoptive parents, this is a favorite story because we define ourselves as parents not by our biological relationships and how much our children look like us, but by our emotional and personal relationships, how we treat each other and meet each others’ needs.  Love, not blood, makes us good mommies and daddies.

How many project managers feel like Choco, wandering corporate halls looking not for a mommy, but a sponsor, asking “Are you my sponsor?” 

What exactly are these PMs looking for?  What do their sponsors need to “look” like?  Who should their sponsor be?

 Too often, like Choco, we think sponsors need to “look” a certain way.  Unlike Choco, however, project managers are typically looking for someone who doesn’t look like them: sponsors need to be “higher” than they are. 

And that is quite true.  Whether it’s resolving cross-functional conflict, securing resources, or championing a project at all levels of the organization, a peer isn’t going to be able to help you with the things that you need from a sponsor. 

But sponsors don’t have to look a certain way.  They don’t have to have a particular title, work in a particular office, or have certain letters after their name to be effective sponsors.  Commitment and availability, not position, make us good sponsors.

I remember a student in one of my Project Management Fundamentals classes who suggested that her company’s CEO was the sponsor of all of her projects.  After all, she explained, that’s whose name was in the box labeled sponsor.  Now, this was at a Fortune 100 company and she was a novice project manager.  Upon hearing this, I thought to myself “I’ll bet you’re good, but I’ll bet you’re not that good.”  I’m fairly certain the CEO of that company did not have regularly-scheduled meetings with her to be updated on the project status.  In fact, I’ll even go out on a limb here and suggest that he probably didn’t even have a clue who she was.

So, unfortunately, that project manager didn’t have a sponsor; she had a name in a box.

Who makes for a good sponsor isn’t so much a function of what they “look” like, i.e., where they sit on the organization chart or whether or not they get invited to the executive 3-day offsite meetings.  It’s more about their ability to “do” what it is the project manager needs from them.   My last article, What’s on Your Sponsorship Short List?, highlighted some of the things project managers may need from sponsors.  The answer as to who will make the best sponsor must start there. 

For example, if capital acquisition isn’t a component of a project, a sponsor may not need to be someone with a say in budgetary expenditures.   Or, perhaps a project in which the project manager is relatively new to the organization and may need more assistance with navigating political terrain may benefit from a sponsor who is a little “closer to home” on the org chart.

Regardless of what is needed from the sponsor, there is one thing that every sponsor must be able to do for any project manager on any project: Be willing and available to develop a real, working relationship with the project manager.  Whoever management decides is the best person to sponsor a project, it must be someone who will actually make time on a regular basis to meet with the project manager and to consume information about the project in order to do what is needed from them.  A name in a box on a project management plan cover page does not a sponsor make.

In fact, I would rather have a “real” sponsor who is less senior but actually interested and engaged in the project and able to meet my needs, than have a senior executive who will never have time for me — even if it means that my sponsor may have to run some things up the chain of command for decisions periodically.  Those time delays are likely to be significantly less than the project inertia that results from an absent, disinterested sponsor.

So, sponsor assigners: When deciding who should sponsor organizational projects, don’t make Chocos out of your project managers!  Find out: What does Choco need and who is the Mrs. Bear who will be available and interested in making sure he gets that?

Because project managers of sponsorless projects wandering the halls may not be a sight that brings anyone to tears, but it is pitiful – and avoidable.

Next, Project Sponsorship – Strategies for Increasing Sponsorship Success.

Are You My Sponsor? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

In our last blogisode, we got some insight into what a Community of Practice is trying to or hoping to accomplish. It is a fantastic start towards a COE and can really help to foster better relationships and maturity in your company. But while the Community of Practice is focused on best practices and good will, the Center of Practice is focused on standards and governance. Now before I go further, let me say that in the end it really does not matter what you call your area or how you choose to categorize it. The goal is maturity and the naming convention is strictly for the concepts we are discussing. “But Bob, doesn’t that fly in the face of having industry standards?” Kind of… and the reason for that is I am 100% dedicated to the idea that this is a cultural evaluation towards maturity. You pick and choose what you want and/or can bite off and how you want it to look. The experts may say Pluto does not meet the “standard” definition of a planet anymore but in my heart Pluto is still a planet, and I know what it is trying to accomplish out there all alone, on the perimeter of our galaxy. You go Pluto!

So if a Community is about best practices and a Center is about standards, what is the difference? Best practices are processes and artifacts that are widely used in the industry and known to increase the likelihood of success on projects when utilized appropriately. They are not enforced. Not all best practices are appropriate to use by a given company given their particular industry, complexity of projects and more. Standards on the other hand are processes and artifacts that are enforced and must be used. They have some form of governance either strict or can be albeit, light in nature.

A Center of Practice is a structure that brings together decision makers of Business Analysis from all over the organization or one governing body (team or person) to define the exact standards to be used by any practitioner of Business Analysis. Templates, processes, diagramming conventions, rules – anything Business Analysis related could be in play (more on this in future blogisodes). Now, I have seen Centers of Practice run by any number of titles including BA Managers, Sr. Directors, Sr. Business Analysts, and Managers of Practice. It depends on the goals for maturity and the overall level of effort and complexity. This could be a temporary assignment, a half-time position or a full time role with a supporting team. The Center of Practice owns the standard and enforces it either through their own structure and team or through an existing structure like a Project Control Office, Project Management Office (depending on how the company is structured). The Center of Practice will have many departments to collaborate with.

So the Community does not have to practice what it preaches until they become a Center. How many licks does it take to get from the Community to the Tootsie Roll Center of Excellence? One… two…. well, more than three I assure you! Again, our time is short but hopefully you are starting to see how your COE could be shaping up!

Next Blogisode: The BA Competency Center: Do you need one? OR… Competent is as Competent does.

Interested in learning more about building a Center of Excellence? Register for our free webinar on Tuesday, June 22nd at 1:00 p.m. CST.  Register

BACOE Blogisode #3: BACOP or BACOP? Community or Center OR… My Community won’t Practice what it preaches! was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

I’m giving a presentation at an upcoming conference called “BA Toolkit: Essential Tools for an Agile Project (or any other for that matter.)” I’m basing the presentation on a recent project that built our CBAP Online Study Exam. One of the tools I used on that project was the State Diagram. The BABOK® notes that these diagrams go by different names such as State Machine Diagram, State Transition Diagram, and Entity Life Cycle Diagram.

It proved helpful for a number of reasons:

1. A state diagram maps the official “states” or statuses that an entity can have, which is to say from initial creation to final disposal. It visually diagrams what would otherwise be a complicated verbal narrative or list. Whenever I map out one of these diagrams, it invariably leads me to find some more subtle states that I might have otherwise have missed.
2. It specifies a sequence of states or statuses that an entity goes through during its lifetime. If an entity changes states, there is always an event that triggers the change. The example below shows sample events (“Offer Made” and “Emp. Is Eligible”) as well as the process to respond to those events (“Accepts Job” and “Employee Retires,” respectively). The triggers and responses are often hidden requirements and the state diagram helps us uncover them. For example, the processes often become use cases and the triggers are an important pre-condition to them.
3. There may be specific things that should be performed when the entity reaches a new state. For instance, when a New Hire “Begins Work” in the example below, the process of “Intake New Employee” gets performed to manage the transition such as election of benefits and recording of personal details.
4. Each state might have its own unique data associated with it. For instance, a New Hire would have less data than an Employee who has started work. Retirees have even more attributes because of their retirement status. The discovery of new states will usually lead to uncovering additional data requirements. I love it when that happens!
5. Before an entity leaves one state for another, there may be some “clean up” activity to be performed. In the example, when transitioning out of the “Former Employee” state, the process of archiving the employee is done. For simplicity’s sake, our example doesn’t show what happens after that.

Here is an example state diagram. It shows 1) Five example states for a Human Resources application, 2) Transitions that reflect the business process in moving from state to state, 3) The event or trigger that causes a move to a new state, and 4) Activities that can take place upon entering or exiting a given state. 

Example State Diagram

To sum up, State Diagrams show the various states which an entity or class flows through during its lifetime (i.e., from creation to deletion). It also shows the events or triggers that prompt from one state to another, and formally labels the transitions. This type of analysis would normally be done only for complex entities that have multiple states or “life cycles.” They can help discover missing data attributes and processes involved in the various transitions.

You don’t need to be a proponent of UML or a specific methodology such as Object Oriented Analysis and Design to use these. They have value for most IT projects, and can help uncover missing requirements quickly. You might also get asked a question on the CBAP® exam, so add studying it to your preparation!

For more information, check out Wikipedia’s page on state diagrams. Make sure to scroll past the obscure entries like the “Directed graph“ and “Mealy machine.” We also cover state diagrams in our Business Process Modeling class and Data Modeling class.

State Diagrams: They Don’t Just State the Obvious was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

If an organization really wants their projects to succeed, and if you’re not convinced of that you’re really in trouble, then why is good sponsorship so elusive? As a project manager, is there anything you can do to improve the chances of a real partnership with a sponsor? That partnership is, after all, one of the top indicators of project success.

In this blog I’d like to suggest that we define what we should reasonably expect from a sponsor. In my next post, I will look at who is the “right” person to sponsor a project. Then I’ll suggest some things that PMs can do to improve their chances of sponsorship success.

So what should a PM expect from a sponsor? Actually, let me rephrase that: What should a PM reasonably expect from a sponsor given the project and the organization? The key word here is reasonable. If regular attendance at team meetings isn’t feasible, for example, then let’s not set anyone up for failure. PMs need to think about their Sponsorship Short List. What are the absolute must haves from this sponsor for this project? Your short list may differ depending not only on the organization, but also the sponsor and the project.

Some Sponsorship Short List options could include:

1. Articulate business and project vision
2. “Prepare” and distributes the Project Charter
3. Obtain funding
4. Define project benefits
5. Facilitate definition of requirements and acceptance criteria
6. Assist in acquiring resources
7. Approve deliverables
8. Make scope decisions
9. Resolve cross-functional and external conflicts
10. Champion the project
11. Provide guidance and direction as needed

Clearly, unless your sponsor is experienced and familiar with best practices, it’s probably not going to serve you well to present an 11-item list and announce that you need all of these things from them. Not only will they insist that they don’t have time (which is probably true), but it may be intimidating. If they’ve never done these things, how are they to know how to do them? No one wants to look incompetent, especially if you’re supposed to be the owner of the project.

So it’s up to you, project manager, to think about it and help them do their job.  Create your Sponsorship Short List: Pick three and define what, specifically, they mean.

If you determine that what you need most is a project champion, for example, what does that mean? What do they actually have to do?  Make a presentation at a meeting?  Include project update on senior management meeting agendas? Come in and cheerlead for the team once in awhile?  Write it down so you understand it. Use small, simple words so you know you understand. (No leveraging synergies!) Then, and only then, present it to them…and set them up for success. When they look good, chances are you will, too.

So if you are feeling like an unsponsored PM, give some thought as to what you’d really like from a sponsor and come up with your Sponsorship Short List.  Remember: Sponsors are sometime lousy at sponsoring because they don’t know what’s expected of them.  Help them understand, and make it palatable.  

It’s probably a learning opportunity for both of you.  If you aren’t used to sponsorship, then you will have to explore how to use them in whatever capacity you have suggested, as well.  Win-win.  It’s a beautiful thing. 

How do you get the best out of your sponsors? I’d love to hear your thoughts.

Next time, Are You My Sponsor?  Who in the organization is the best candidate for project sponsor.

What’s On Your Sponsorship Short List? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

So in my last blogisode I talked about the many paths to Business Analysis maturity and the need for you to first start with root cause analysis to determine why you think you need a BACOE.  Did you go through your Five Whys exercise?  If so, you may have found that your organization lacks standards, and the root cause for that might have been something like insufficient budget to document or the previous attempts at standardizing failed so we can’t do that again!  Or perhaps you have some standards and you found out that your organization lacks the ability to measure Business Analyst performance effectively.  That might have had a root cause like dispersed management in a matrixed environment.  Whatever the reasons, both make sense to move forward with a full blown BACOE model, right?  Well hold a minute!  This is why I say getting started is hard. 

There is a LOT to a BACOE and, although these are components of a BACOE, they are not all encompassing.  Calling yourself a BACOE may imply something that may not be what you need/want and/or misrepresenting your effort.  Trust me on this – I have learned the hard way!  Now, personally I love the concept of the BACOE, but it can be nuclear in proportion (which is why one must love the bomb if one wants a full BACOE).

The next step is to understand the different names/approaches and what they mean to your effort.  So what is in a name?  Let’s explore.  BA Community of Practice.  BA Center of Practice.  BA Competency Center.  BA Center of Excellence.  These are a few of the main concepts out there.  Really?  Really!!!  The approach and the name describes what your focus is and  is also a selling point when it comes to getting support from your management or community both now and later (more on that in future blogisodes).  So I want to briefly describe each approach so that you can have a better frame of reference for matching it up with your root cause analysis.

BA Community of Practice.  The Business Analysis Community of Practice is a structure that brings together practitioners of Business Analysis from all over the organization to discuss best practices, successes, opportunities for improvement, coaching, solicitation of ideas and other needs (like venting-which is healthy).  This is done regardless of methodology used or titles bestowed.  Just like the Girl Scouts – they are a community with a specific focus (oh Girl Scout cookies, why do you tempt me so!).   The Community is often run by a Business Analysis change advocate/champion in the organization or by a committee of peers with representation from multiple departments.  The Community of Practice generally has no authority to make changes to company policies, templates or processes.  It can be run in person, virtually, or both and may meet quarterly, monthly, or weekly depending on need and bandwidth.  It should be a safe environment where people are free to exchange information with the goal for improving overall quality.

It is already the end of another brush with danger and thrills – the BA Center of Practice definition is next!

Next Blogisode: BACOP or BACOP?  Community vs. Practice  OR…  My Community won’t Practice what it preaches!

BACOE Blogisode #2: Maturity is easy, it’s the getting started that’s hard! OR… How I learned to stop worrying about BA maturity and love the bomb! was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

The impetus for this blog comes from having just taught a successful training class in Data Modeling to a mixed group of BAs, BI specialists, technical architects, and business SMEs (subject matter experts). What made it successful was not only the learning that took place, but also the students’ willingness and eagerness to apply this technique back on their jobs.

I’ve been doing and teaching data modeling for as long as any business analysis technique. Many organizations I encounter think of data modeling as being technical and not BA work. Of course I feel differently, and have long viewed logical data modeling as business analyst work. The IIBA® agrees by including this technique in the BABOK.

Regardless of how you or your organization categorize Data Modeling (DM), you need to be prepared to answer questions on it for the CBAP exam. Here is a short over view of some Dm essentials:

• Data models capture the static data requirements of an organization for its ongoing business operations and decision support. It does that by defining and structuring entities, relationships between the entities, and adding detailed attributes into the entities. There is usually ancillary documentation you need to include that doesn’t fit strictly into the model. Two major styles of data models are entity-relationship diagrams (ERDs) and class diagrams.
• Concepts. Entities are the basic building block of a data model. The BABOK goes a little abstract on us by categorizing these as “concepts.” No one I know of except a textbook refers to entities or classes as concepts. The BABOK does it because an entity could also be represented by a class if you are using UML (Unified Modeling Language). In short, a concept is an entity or class depending on the DM style employed, and the term may appear on an exam question. I’ll use the term “concept” interchangeably with entity and class.
• Entities/Classes represent the people, places, things, processes, or events within the business. They have multiple instances that turn into rows in a relational database, and attributes, which become columns or fields in a database.
• Relationships are significant business connections or associations between “concepts” (there – I used the term). Relationships can be “one-to-one,” “one-to-many,” or “many-to-many.” The BOK uses the term “cardinality” to refer to the number of entity elements that are associated, namely one or many. Relationships may also be categorized by being optional or mandatory, such as “zero or one” or “at least one.”
• Attributes are the detailed facts about the “concept.” An ERD or class diagram typically lists the attribute name, relying on ancillary documentation for specifying domain ranges, the type of data an attribute can hold, and the definition of each attribute.

Here is an example data model, illustrating the terms above, and highlighting the four types of cardinality. Don’t be surprised on the CBAP exam if you are asked to interpret a diagram such as this. That type of question demonstrates the application of a technique, not just understanding the terminology.

Data Modeling is an important requirements analysis technique, and one you are likely to be tested on. Make sure you understand this technique for the exam, and then work at applying Data Modeling on the job. I plan to blog about that in the future – after I finish all the BABOK techniques!

Data Modeling – Why is that Technique in the BABOK? was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog

Round One

Relative sizing of user stories (Scrum)

• T-Shirt Sizes. For release planning we might use estimates of relative size. When less is known about the user stories for a release, we can estimate using a broad brush approach. Based on such criteria as how complex we think the user story is, how much effort it will take, and the unknowns or doubt, we give it a T-shirt size (XS, S, M, L, XL). We can then compare all the user stories and assign relative sizes. For example, we can take one user story and based on the above criteria assign it a T-shirt size of “Large.” We can then compare all the other stories against this “Large” size and assign the relative value of each story. This relative size estimating can help the Product Owner decide which user stories to prioritize for a release.
• Story points. We can then assign each T-shirt size story points based on an arbitrary scale, such as the Fibonacci number sequence (1,2,3,5,8,13,21…). If a user story is Medium, for example, we might assign 8 story points. If Large, 13. We can then translate the T-shirt size of all the user stories into story points. It’s important to remember that these story points are still relative. It really doesn’t matter if a Small is 2 or 3 points, as long as it’s consistently applied.

Waterfall relative sizing of projects, phases, deliverables, tasks.

For years we have used use relative size estimates on traditional projects. I have found this most effective when actuals have been collected over enough time to have confidence in the numbers. While I have only used relative sizing on projects and deliverables (such as a small, medium, or large report), I know of teams that have used them on phases and tasks as well. As with Scrum, we usually base traditional relative sizes on complexity, effort, and doubt (risk).

Round 1—Scrum wins, but it’s not a knock-out.

In my experience using relative sizes on traditional projects is often done to short-change the planning process. With Scrum the relative size of the user story actually gets refined as it approaches the sprint in which it gets delivered. While some traditional teams have the discipline to refine the estimates (as a project manager I always encouraged it), many more give in to management’s pushback about not changing the date, scope, or cost. Scrum processes, by their nature, encourage change and refinement; traditional processes do not.

Round Two

Scrum Planning Using Delphi (Planning Poker®)

 Planning Poker uses a kind of Delphi technique to reach consensus on the relative size of the user stories. Each person on the delivery team (not the Product Owner) is given a deck of cards, each card with a number. For example, if using the Fibonacci scale, the deck would have cards, each containing a number in the scale (1,2,3,5,8,13,21, etc.) going as high as desired. The Product Owner explains the details of the user story and at the count of three team members turn over the card with the points they think most appropriate. For example, two team members have turned over a 3, one a 5, two an eight, and one a 21. They discuss their reasons for “playing” their cards. Then at the count of three they turn over a card, the same or different from last time. Again, they explain their rationale. This process continues until consensus is reached.

Traditional projects using Delphi,

The Delphi technique involves a group of experts providing their estimates anonymously. Like Planning Poker, there are rounds. Although this can be done electronically, the experts usually write their estimates on a piece of paper.  A neutral party takes the estimates, shuffles them, and reveals them to everyone at the same time. No discussion is supposed to occur. For the next round and based on seeing the estimates of the others, each expert provides a written estimate which can be the same or different from the previous round. The process continues until consensus is reached.

On traditional projects I have tried using Delphi anonymously only once. It didn’t work. I have found the power of Delphi is in the discussion of each person’s assumptions about the estimates.

Round 2—Scrum wins, but again it’s not a knock-out. I love the Delphi technique. I love having the team reach consensus on estimates, whether traditionally or through Planning Poker. It provides team accountability for the estimate, and increases the chance of team and individual commitment rather than compliance. So what difference does it make whether traditional Delphi or planning poker is used? Everyone can understand Planning Poker. I have seen teams take to this technique immediately. But while Scrum makes things easy and practical, the traditional Delphi feels arcane. In addition, the traditional approach has some points taken off for having to use experts and for the required anonymity.

So, the current score is two zip. But the match is not over. Much more to come…

A Heavyweight Fight–Scrum vs. Waterfall: Estimating Part 1 was posted at ProjectBrief Blog. | http://www.watermarklearning.com/blog