Skip to main content

Tag: Best Practices

Use Case Preconditions: A Best-Kept Secret?

Written by Willem Van Galen on . Posted in Articles.

Introduction

WillOct15th1Alistair Cockburn opened my eyes to the essence, elegance and effectiveness of use case preconditions.  In [1], he discusses preconditions in just a dozen paragraphs, but these contain two statements that revolutionized my understanding of preconditions and their counterpart, postconditions.

This article starts with those statements, illustrates what I believe they imply, outlines key fundamentals, discusses how preconditions and postconditions reflect sequential use case dependencies and promote loose coupling between use cases, and ends with a reflection on enforcing preconditions.

Based on personal experience, as well as a cursory check of the Internet, use case preconditions still seem to be a best-kept secret.  This article is intended to help change that.

Bless you, Alistair

Odd as it seems in retrospect, until I read Alistair Cockburn’s inspiring book [1], use case preconditions were in my blind spot.  That changed with two statements at the start of the book’s chapter 6:

  • “[A use case’s preconditions indicate] what the system will ensure is true before letting the use case start.”*
  • “Generally, a precondition indicates that some other use case has already run to set it up.”

After reading these two statements, the clouds parted, an angelic chorus hummed a mystical chord, and a bright eco-friendly light bulb appeared above my head; I had discovered a nugget in Alistair’s gold mine of a book.

* A use case’s postconditions indicate what will be true after the use case finishes.

A picture tells the story

The next diagram illustrates the use of preconditions, using a simplified example.

WillOct15th2

This diagram reflects the preceding two statements in that:

  • A user can only initiate a use case when the system has concluded that the use case’s preconditions are true.
  • A use case’s preconditions result from executing one or more other use cases.

If we imagine a corresponding user interface, the function button that corresponds to a particular use case is enabled (a user can click on it) when the use case’s preconditions are all true, and disabled (grayed out) when at least one of the preconditions is false.

Another way to view this is as part of a “no false hope” strategy. A user is not given the impression that he can complete a certain function use case he can’t (i.e., if the conditions had been enforced as part of the use case instead of as preconditions, and at least one turned out to be false).

Some fundamentals

This section is based on [1] and on personal experience.

A use case’s preconditions can only exist within the system

Since a use case’s preconditions are enforced by “the system,” they can only exist within that system, which wouldn’t be able to detect them otherwise. A use case precondition cannot refer to a condition in the physical world that isn’t represented within the system.

The reflection at the end of this article shows that when it comes to enforcing preconditions, “the system” in its broadest sense refers to “the systems environment.”

A use case’s preconditions are the same for all its scenarios

Since a use case’s preconditions are true before the use case starts, it follows that they apply to whatever scenario* unfolds during an execution of the use case. This is one reason for not bundling multiple user functions into one use case (e.g., bundling Create, Read, Update and Delete functions into a Maintain use case), for they typically have different preconditions (and postconditions).**

* A scenario is a possible path through a use case.

** Moreover, it’s impossible to show in a use case diagram differences in user authorization; if one role (actor) is authorized to initiate one set of the bundled functions and another role (actor) is authorized to initiate a different set.

A use case doesn’t check its preconditions

Since a use case’s preconditions are “enforced by the system and known to be true” by the time the system allows the use case to start, they are “not checked again during the use case’s execution.”  This is why:

  • Preconditions are also called assumptions (a use case assumes they’re true).
  • There is no need to write use case steps that check preconditions (doing so would miss the point of using preconditions).

Being mindful of these fundamentals yields clear preconditions and use case flows.

Of use case dependencies

Sequential dependencies

A use case precondition reflects a sequential dependency between use cases.

  • Use case B with precondition C can only start after use case A has produced C as a postcondition.
  • Use case B is executed after use case A; their connection is asynchronous.

Functional dependencies

In contrast, an include relationship (and a directed association as well) reflects a functional dependency between use cases.

  • When use case A has an include relationship (or a directed association) to use case B, it means that the functionality of use case B is part of the overall functionality of use case A.
  • Use case B is executed as part of use case A; their connection is synchronous.

Impact on use case models

This difference means it’s incorrect to use a functional relationship to represent a sequential dependency between two use cases—instead, use postconditions and preconditions.  This is summarized in the diagram below for include relationships, using a simplified example.

WillOct15th3

Conditions enable loosely coupled use cases

What is loose coupling again?

Two use cases are loosely coupled when:

  1. The execution of the first enables the execution of the second.
  2. Neither has any knowledge of the other.

Kinds of loose coupling

One kind of loose coupling—between publisher and subscriber use cases connected via event objects and an event manager — is outlined in [2]. 

A different kind of loose coupling—between upstream and downstream use cases connected via conditions and user actions — is addressed in this section.

Point 1: Function use cases enable function use cases

In the above diagrams, postconditions produced by the execution of one or more upstream use cases enable the execution of one or more downstream use cases.

  • As soon as a downstream use case’s preconditions are all true (i.e., they reflect postconditions produced by the execution of one or more upstream use cases), a user can initiate the downstream use case.

Point 2: Function use cases don’t know each other

In the above diagrams, upstream and downstream use cases don’t know each other.

  • An upstream use case doesn’t know which downstream use cases a user can initiate next.  It doesn’t pass control to any of them.  It only produces certain postconditions.
  • A downstream use case doesn’t know which upstream use cases a user initiated previously.  It doesn’t accept control from any of them.  If initiated by the user, it trusts that its preconditions are true, no matter which use cases produced them.

Actions outside function use cases

As noted earlier, in a use case model the system is understood to take actions outside use cases, for example by ensuring that a use case’s preconditions are true before allowing the use case to start.  Similarly, a user can take actions outside function use cases, for example by selecting an object from a list before initiating another use case.

As setup for an example of the latter, assume that:

  • The personal banking website from the first diagram also has function use cases View Accounts Summary, View Account Transactions, View Account Details and Change Account Details.
  • The postcondition of the customer-centric View Accounts Summary use case is “The user is presented with a summary of the customer’s accounts.”
  • A precondition of the three account-centric use cases is “The account has been identified.”

An implied user action is the selection of an account from the list of accounts presented by the View Accounts Summary use case.  This selection, not the use case, creates the precondition for the three account-centric use cases. 

This user action is implied because it is not part of any of the use cases.

  • Adding it as the final step of the View Accounts Summary use case would make the use case overshoot the user’s goal, which is to view the accounts summary.
  • Adding it as the first step of the account-centric use cases would make using the above precondition impossible and thus undermine the loose coupling between these use cases and the customer-centric one.

The implied system and user actions must be accommodated in the user interface derived from the use case model.

Tip: Don’t state who (an actor) or what (a use case) produced a precondition.

  • Stating an actor introduces irrelevant, distracting and potentially misleading assumptions (what if the use case model is enhanced with a new actor who can also produce the precondition?)
  • Stating a use case violates the principle that loosely coupled use cases don’t know about each other (and what if the use case model is enhanced with a new use case that can also produce the precondition?).

The condition is what matters, not how it came to be.

Benefits

Loose coupling between use cases in general:

  • Inherently leads to use case models that are easy to create, understand and evolve.

Loose coupling between function use cases in particular:

  • Enables analysts to produce use case models without built-in assumptions about the corresponding user interface (e.g., the sequence in which functions get presented).
  • Gives user interface designers the greatest freedom in designing that user interface (e.g., a given function may be launched from multiple screens that each in its own way ensures that the preconditions of the corresponding function use case are met).
  • Allows user interface designers to restructure an existing user interface without the need to change the corresponding use case model (e.g., moving function buttons around but adding no new functions).

Using conditions and user actions to model loosely coupled function use cases results in a highly modularized use case model whose function use cases are:

  • Context-aware (aware of their preconditions, but not of other use cases).
  • Single-purpose (because defining one set of preconditions for multiple purposes usually doesn’t work).
  • Lean (because they are single-purpose and their preconditions are assumed).

When a system is modeled like this, it truly reflects the notion that the use cases represent the system’s operations, as mentioned in [3], because each use case represents a distinct capability the system provides to its users.

Preconditions for other use case types

The preceding deals with function use cases, but preconditions and postconditions can be used for the following use case types as well.

  • Batch process (<>) use case.  As for a function use case, the preconditions reflect the use case’s sequential dependency on one or more other use cases. 
  • Subscriber service (<>) use case.  As outlined in [2], use cases of this type are inherently modeled to be initiated by the event manager, and so they assume the event manager as their context.  This means they have a standard set of preconditions (see [2]).

What enforces use case preconditions?

It’s one thing to state that the system ensures a use case’s preconditions are true before allowing the use case to start, but in a logical use case model it is typically implied that the controller is part of the system.

For a comprehensive understanding of controllers, we have to consider the physical implementation realm as well.  The following table summarizes typical controllers and, relating the physical to the logical, the types of use case they control.

WillOct15th4

This summary shows that the enforcer of a use case’s preconditions isn’t necessarily part of the system to which the use case applies, so in the broadest sense “the system” means the systems environment when it comes to enforcing preconditions.

In conclusion

If you’re new to use case preconditions, I hope this article has whetted your appetite for them.  If you’ve used preconditions before, I trust this article reconfirmed their usefulness and maybe even added a new angle.  Preconditions certainly aren’t the only gold nugget in [1], and perhaps there’ll be opportunity to reflect on others.

Don’t forget to leave your comments below.

 References

[1] Alistair Cockburn, Writing Effective Use Cases, 12th Printing, November 2004.

[2] Willem Van Galen, Modeling Loosely Coupled Use Cases, 30 April 2012, http://www.batimes.com/articles/modeling-loosely-coupled-use-cases.html.

[3] Willem Van Galen, The System: Don’t Model A Use Case Without It!, 11 September 2012, http://www.batimes.com/articles/the-system-dont-model-a-use-case-without-it.html.

The Broken Telephone Game of Defining Software and UI Requirements

Written by Martin Crisp on . Posted in Articles.

The broken telephone game is played all over the world. According to Wikipedia, the game is played as follows: “one person whispers a message to another, which is passed through a line of people until the last player announces the message to the entire group. Errors typically accumulate in the retellings, so the statement announced by the last player differs significantly, and often amusingly, from the one uttered by the first.”

This game is also played inadvertently by a large number of organizations seeking to define software and UI requirements by using information passed from customers to business analysts to UI/UX designers and then to developers and testers.

Here’s a typical example:

  • The BA or product owner elicits requirements from a customer and writes them down, often as a feature list and use cases.
  • The use cases are interpreted by the UI/UX team to develop UI mockups and storyboards.
  • Testing interprets the storyboards, mockups, and use cases to develop test cases.
  • The developers then interpret the use cases, mockups and storyboards to write the code.

As with the broken telephone game, information is altered with each handoff. The resulting approach includes a lot of rework and escalating project costs due to combinations of the following:

  • Use cases don’t properly represent customer requirements.
  • UI/UX design is not consistent with the use cases.
  • Incorrect test cases create false bugs.
  • Missed test cases result in undiscovered bugs.
  • Developers build features that don’t meet customer needs.

The further down the broken telephone line the original requirements get, the more distorted they become. For this reason, UI storyboards, test cases and code typically require a lot of reworking as requirements are misunderstood or improperly translated by the time they get to the UI and testing teams.

How Can We Reduce the Broken Telephone Effect?

The good news is that there are some reasonably simple changes to processes and deliverables that will decrease the broken telephone effect. The following techniques share the goal of reducing handoffs and translations.

Interview the customer with cross-discipline teams

One method is to involve the BA, UI/UX and quality assurance people directly in the elicitation process with the customer. You can even make a case to include the lead developer as well. Having all disciplines represented during the interview process lets each party hear requirements directly from the customer, reducing the reliance on BA documents alone. An equally important benefit is that each discipline brings a different perspective, which can lead the interview process down different paths of conversation and requirement gathering.

For example, the QA resource may ask more questions about the requirements related to edge or error conditions than the BA or UI/UX resource. Putting a UI/UX member in front of the customer will provide a chance to understand features that are frequently used to manage the cognitive load of the end user.

Combine and evolve use cases, UI mockups, and UI storyboards into an integrated deliverable

Another approach to reduce the broken telephone effect is to avoid creating use cases, mockups and storyboards as separate deliverables by combining them into one “integrated deliverable.” To create an integrated deliverable, start with the use case and attach UI mockups to each step. This automatically creates a UI storyboard that has the same steps (including main and alternate flows) as the use case, and means they don’t get out of sync. Also, since the UI mockups are attached to each step, you know they will be consistent with the purpose and requirements outlined in the step.

Often, new requirements or changes to existing requirements emerge, and if your storyboards and mockups are separate from the use cases, the original use cases are not updated. This creates confusion for your developers, testers and stakeholders. Combining your use cases, mockups and storyboards into one integrated deliverable makes it much easier to keep all three in sync, dramatically reducing the potential for conflicting requirements.

The integrated deliverable approach encourages collaborative and combined authoring and review of use cases and UI/UX design by your BA and UI/UX teams, resulting in more accurately defined and understood requirements.

To bring this concept to life, here’s an example that starts with the use case defined by the BA or product manager, without any mention of UI-specific requirements.

Use Case: ATM Cash Withdraw

The steps with the Y-shaped symbol are steps with alternate flows.

Oct9thMartin1

Alternate Flows

Oct9thMartin2

Oct9thMartin3

When the UI/UX team starts attaching UI mockups to each of the steps, a UI storyboard is created that uses the same exact main flow and alternate flows as the use case. A UI storyboard expressed in terms of a main flow and alternate flows has the benefit of reducing the number of traditional linear storyboards. If you were to create traditional UI storyboards for each of the unique paths through the use case above, you’d have 11 in total, with duplicated steps across them. UI storyboards with main flows and alternate flows reduce rework and errors that pop up in linear UI storyboards.

You can do this in Word by inserting UI mockup images created in a different UI mockup tool, but keeping the UI mockups up to date in the will become time-consuming and error-prone. Products such as PowerStory (a plugin for PowerPoint) make this easier by enabling you to combine use case steps with UI mockups to create UI Storyboards.

In the following screen shot you will see that PowerStory adds a panel specifically designed for creating main flows and alternate flows of use cases, and associates the steps in these flows with typical slides in PowerPoint.

Oct9thMartin5

As before, the steps with the Y-shaped symbol beside them indicate an alternate flow. When you hover over the icon you can view and enter the alternate flows associated with that step.

Oct9thMartin6

PowerPoint is an extremely powerful tool for creating UI Mockups that can support more UI design ideas than typical wireframe mockup tools, especially with plugins like PowerMockup and Microsoft’s upcoming storyboarding plugin.

Write use cases and UI storyboards with testing in mind

Test cases typically include a “user action” followed by an “expected result.” If you spend a little more up-front time defining which steps are “user actions” and which steps are “expected results” when creating your use cases and UI storyboards, you can save your testing team time. Use cases are well suited for this approach by defining the principle actor for each step. Any step where the actor is a system should be classified as an “expected result” step for the test case, and any step where the actor is an end user should be labeled “user action.”

One of the test cases derived from the combined use case defined above is shown below, following the rule that a step with an end user actor is an action and a step that has a system actor is an expected result.

Oct9thMartin4

Automate the creation of your test cases directly from your use cases

Using tools that will automatically generate test cases from your use cases and UI storyboards will save you a significant amount of time and money typically spent by your testing team creating manual test cases. In the context of this article, it also eliminates a handoff and thus mitigates the broken telephone effect. When QA teams interpret requirements and translate them into test cases, they might misunderstand requirements and create faulty test cases and/or miss requirements and their corresponding test cases.

Key Points to Take Away

Developing software requirements, UI designs, and test cases can mirror the broken telephone game we all played as kids. Every time we pass information on, it gets changed and misinterpreted, leading to increased project costs and the delivery of the wrong solutions to your customers. Following the steps outlined above, you can reduce the broken telephone effect and follow a more streamlined process to clear and lucid product development.

Don’t forget to leave your comments below.

The Top 5 Mistakes in Requirements Practices and Documentation

Written by Angela Wick on . Posted in Articles.

FEATUREMay29thIn my work with dozens of organizations improving business analysis practices, the following are the most common themes I see hindering the great value that good business analysis practices can provide.

1) Lack of collaboration and review of requirements

Collaboration and review of requirements should be an ongoing process of meeting, discovering, and collaborating to share information and context. Verifying that requirements met the needs of others to guide further work and validating that the requirements will add value to the business are critical pieces to this review and collaboration.

The mistakes I typically see in this area are teams that “gather” and “collect” requirements from stakeholders rather than using proven successful elicitation, discovery, and validation techniques. Following a “gather” and “collect” mindset sets a team up to jump to the solution too quickly before truly understanding the business needs and value required by the stakeholders.

The BA is often assigned to the project after business needs and values have already been discussed and the stakeholders pressure the BA to just move forward. This is the most important time for a BA to use powerful collaboration techniques that help the stakeholders feel that they are not restating the same information but are improving the business value proposition the project is set out to achieve.

Some teams see requirements reviews as sufficient collaboration. With requirements reviews I often see the following:
• Lack of review
• Reviewed, but missing critical stakeholders and consumers of requirements
• Reviewed but as a formality, and stakeholders struggle to truly understand requirements documentation

Ideally for requirements reviews to be successful, those using and signing off on requirements need to be fully engaged in reviewing requirements, verifying they are understandable, cohesive, and usable for the further work to be done, and validating the business value and intent of the requirements. To achieve this, BAs need to ensure that documents are presented and communicated in ways that are understandable to all audiences and the review process engages all audiences to fully participate in the review.

2) Not differentiating between capabilities, rules, project tasks, and design

Many requirements documents that I see in a large number and variety of organizations are missing the essence of what requirements are. The mistake I see is requirements documents lifting project tasks, detailed technical design, and business rules without listing the context and capabilities needed. This sets the project and solution up for a multitude of missed requirements and missed value to stakeholders. Business and solution requirements are capabilities needed by a solution to achieve a desired change in the business. They are not project tasks lists, technical design details, or bullet lists of business logic. Focusing on the true requirements instead of the project tasks and design will shorten the requirements timeline.

Project tasks need to be in a project plan of some sort, and design should be happening progressively as requirements are discovered and must account for feasibility and alternatives. Design needs to be differentiated from what the requirements are, and this can occur in a separate document or not, but it needs to be differentiated. It is no fun to manage requirements change when the requirements document is really tasks and design; this will cause more change management administration than needed. Requirements change becomes much more manageable when it is truly business and solution requirements that are changing. Changing design details and project tasks is likely to happen with more frequency and may not impact the end result, and a failure to differentiate can cause costly rework and unneeded administrative tasks.

Business rules are critical to successful requirements, but I often see requirements only in the context of business rules, and sometimes up to 90% of a requirements document is a listing of business rules. Business rules listings without the context of processes, people, data definitions, sets, projects up for missed requirements, inefficient and inconsistent implementation of business rules. Understanding the business rule outside of technology enablement is crucial to improving the consistency and efficiency of business rules. Differentiating business rules from requirements is critical to understanding and analyzing the capabilities needed to implement the rules.

3) Lack of context and visuals

Context and visuals provide our requirements readers with brain candy. Many studies show that visuals are consumed by the brain much faster than text and help depict relationships, whereas text is processed in a more linear fashion in our brains. Cognitively, visuals are proven to be more effective than text at increasing a reader’s comprehension and retention. On the other side, visuals without text can be too ambiguous. So, why do so many requirements documents lack visuals and context that would help readers comprehend and retain the very information BAs are asking them to approve? As Bas, visuals are sometimes present but often are too complex to engage our readers and need to be simplified. Sometimes our visuals as BAs are design oriented rather than intended to help readers understand context, interactions, and relationships.

Great requirements are documented in a way that allows the reader to choose the level of detail they would like to consume, provide visuals and context of varying levels of detail needed to guide further work, and provide text that clearly traces the visual and context representing the text.

4) Too much focus on the as-is current state

Projects and business analysis work is about changing the way organizations operate. It amazes me how much time is spent on documenting the as-is; I am not advocating ignoring the as-is or current state, because it is needed to understand the gaps that must be crossed to get to the future desired state. The challenge and mistake I see teams making is never getting to defining the gaps and future state. And, sometimes all of the context and visuals are about the current state with nothing showing the context or visuals for the future state.
Our requirements need to understand the current state, but the requirements themselves should represent the gaps and future state. We are not asking our stakeholders to approve the current state. Instead, they are asking us to help them change, hence we need to define the future state. Our requirements need to answer the questions: Why are we spending money on this solution? What value will the solution bring?

There are many statistics out there about the percentage of functionality in current systems that is not used; the numbers typically range between 60-80%. This raises the question of why we would document requirements for the future the way the system works today when 60-80% is not even used today? After all, today’s system was likely designed 10, 20, or even 30 years ago and we can’t possibly compete in todays business environment by developing solutions based on functionality designed for business years ago. After all, how will this take the organization into the future?

Great requirements practices and documents show how the current state is going to change, what the future state is, and the gaps to get there. There are many areas of solutions where the current rules, process, and technology will be leveraged in the future state, and this is where we need to ensure we are focused on the future by defining what pieces will move forward, and we shouldn’t spend too much effort on current state items that will not carry forward. This is done by identifying the current state at a higher level and questioning if this piece will continue to add value in the future state vision. At that point, a BA should only go into details if the value is justified.

5) Allocating requirements too early to the applications they will be implemented in

When evaluating business analysis practices and how they align with software development processes, I often see that the requirements are being allocated to software applications before the requirement itself has much context or elaboration. Understanding the requirement and business need is needed before we can specify what system or application will be changed or built to implement the requirement. The practice of assigning the technology to a requirement before the BA is assigned or before the requirement is vetted defeats the purpose of business analysis in many ways. This practice also makes requirements change a huge challenge. As we discover and elaborate requirements, we often find that the initial idea on implementation is not feasible or optimal. If the requirements process has already allocated the requirement, it takes a change request to change that in some organizations. This is where the process hinders good business analysis. Many times this practice is not in the control of a BA, but I do believe that a BA can collaborate with others, and elicit and document requirements in a technology-agnostic manner to facilitate the discovery of other ways to implement requirements.

Great requirements practices focus on the user, process, rules, events, data, and non-functional needs before deciding which exact implementation technology will be used. This allows the team to discover the true business need and explore options and alternatives that may not have been previously thought of. It also helps ensure feasibility prior to committing to a specific solution design.

Let me know your thoughts on the common mistakes in requirements practices and your challenges in these areas.

Don’t forget to leave your comments below.

The Top 10 Business Analysis Skills for 2012

Written by Angela Wick on . Posted in Articles. 1 Comment on The Top 10 Business Analysis Skills for 2012

I like to think of the BA role as a broker of information, getting big picture and details from many different people, groups, executives, subject matter experts, vendors, technical resources, etc . . .

what the BA does with all this information and how it gets communicated and repurposed for each audience is opportunity for a BA.

Today’s trends are pointing towards the following themes for BAs:
– Business Agility
– Innovation
– Engagement of stakeholders to drive agility and innovation

The needed skills to meet these trends in 2012:

1) Conceptual Modeling Skills
Engage your stakeholders with more meaningful dialog!  Conceptual Modeling of the business view of the solution has always been a critical tool to help bring business, technology, and delivery groups together in defining solution scope.  I have had many BAs tell me that they do this and show me their conceptual models.  What I find when reviewing the models is more of a technical architecture or data context diagrams.  Technical architecture and data context diagrams have their place, but the critical skill I am seeing as a gap in BA skill sets is the business view (vs. technical view) of the solution scope, this will be critical to engaging stakeholders and setting the stage for innovation

2) Communicating Details and Concepts
Similar to the conceptual modeling skills is communicating various levels of detail appropriate to the audience.  This can be especially difficult when you have various stakeholder needs on the team or in the meeting, and many times multiple views is needed to ensure the right message is communicated to all audience needs.  Where I see the gap today is details are not organized to be digestible and understandable to many audiences and there may be a lack of conceptual and context to accompany the details.  Without the concept and context information, the details – even when well organized – may not be understood or thought of in with the frame of mind that the BA needs from the stakeholders.  Rethink requirements packaging, does the same document need to go out to everyone?  Or, can each audience be given a guide as to which pages/sections are most pertinent to them?  Just a few ideas to help stakeholders consume what is important to them.

3) Curiosity
How curious are you as a BA?  This has always been a critical skill for BAs.   Ensuring curiosity in finding the root cause of the problem or opportunity, getting the  right audience, usage, context, purpose for requirements requires a strong level of curiosity in BA work.  Curiosity will go far in 2012 for BAs wanting to build competency and skills in the world of mobile apps, cloud computing, and continuing agile trends.  Curiosity will make some of the unknowns of today easier to work within, a curious mindset will take BAs into communicating the unknown and help organizations innovate.

4) Decomposing the Abstract into Details
I have to call this out separately from Conceptual Modeling and Communicating Details and Concepts.  The same themes are in play, but yet executed a bit differently and in different scenarios.  Decomposing the abstract into details is also referred to as “critical thinking” and sometimes “system thinking”; taking something large, ambiguous, and abstract and breaking into smaller pieces, patterns, and views.  It is about helping others see the details and big picture from different perspectives, helping stakeholders with varying points of view and priorities see where their details and others fit into the bigger picture.  It will also help BAs better estimate and work with PMs on the status and risk of requirements.

5) Mentoring and Coaching
As the BA role becomes increasingly more valued in organizations, two things will happen:  1) Organizations will need a career path for Sr. BAs, and 2) Organizations will need to develop internal strategies to develop more talent in the BA role and Sr. level skill set.  Mentoring and coaching skills are key for Sr. BAs in both of these strategies.  Mentoring and coaching done by Sr. BAs will develop leadership competencies in the Sr. BAs while developing BA competencies in new or more inexperienced BAs in the organization.  Sr. BAs who have the opportunity to mentor and coach will develop further leadership competencies needed to elevate the competencies of the BA team as a whole.

6) Communicating Risks
Project Managers focus on risks to the project budget, schedule and scope.  A BA needs to focus on risks to the business value of the solution and communicating the risk.  BAs are in a prime position to see the details and big picture view; this includes seeing the risks to the project, delivering a solution that does not maximize business value.  I find that BAs have an intuitive sense of this, but often struggle to communicate the risk in a way that gets leadership attention.  In order to get leadership attention to the business value at risk, BAs will need to develop skills in communicating the true business impact of the risk.  This means going beyond communicating in terms of the features and functionalities of the process or software, and going beyond that, there is not enough time for requirements to be done right. It means communicating the impact it will have on the business operation or strategy.  For example, when the functionality of a point of sale application has a requirements conflict in the process of accepting payment from customers, the focus needs to turn to the impact of the conflict on the customer service representative’s ability to serve the customers and the customer experience vs. the technical details at risk of the requirement.  In the heat of requirements and design details, we often let the details drive risk discussions and never get to the bottom line impacts that can really propel leaders to make the right decisions.

 

7) Leveraging the “parking lot”
Are you running your meetings or are meetings and stakeholders running you?  Many BAs get into tough situations in requirements meetings and feel that other agendas and personalities are driving their meetings astray.  Using a “parking lot” (simple visual list of items that do not fit into the meeting agenda to be followed up on or scheduled into another meeting) to manage and control the meeting agenda, content, level of detail and difficult personalities is a key strategy.  Most importantly, make sure that the parking lot is visible to everyone in the meeting.  Having the parking lot in your notebook or on your laptop does not show others that you have their ideas and concerns captured to discuss at a later time.  Be empowered to take control of your meetings!

 

8) Change Management
Embracing the BA role as an agent of change will continue to show the value the organization the value the BA role brings to the organization. Projects are about business change; the BA role is about bringing the most value possible in a solution to address the business change.  The role of a change agent in the BA is critical to ensuring all impacted parties are ready for the changes needed to accept the solution.  Understanding how changes and solutions impact the stakeholders operations, processes, attitudes and behaviors is a key skill in maximizing the success of the new solution and the business value it brings.

9) Asking WHY?
I love the word “Why”, but hate to use it.  My challenge to readers of this blog is to help one another find ways to ask “Why”.  Many times using the word “Why” can come across wrong to the other person, it can seem defensive and the other may wonder why (no pun intended) you are asking.  Finding different ways to ask “why” can alleviate this dilemma.  My favorite ways to ask “Why?”:  Tell me more about what is behind the need for abc?  What does success look like?  What would happen if this project does not get implemented? What are yours?

10) Impromptu Whiteboard Drawing
In 2012 when innovation, agility, and engagement are the trends, being able to spontaneously draw will lead to stakeholders to a deeper level of engagement.  Getting up to draw shakes up the flow of boring meetings, engages others to focus back in on the discussion, and brings out humor – let humor be a friend. You don’t have to be an artist to draw concepts on whiteboards that generate great dialog, discussion, creativity and innovation.  It also does not have to be you that does the drawing; ask someone else to draw what they are thinking and your meeting will benefit in many of the same ways.  When the drawing yields powerful and meaningful discussion, be sure someone takes a picture with their phone.

No matter that type of BA, no matter what the industry, these skills in 2012 will set your projects up for deeper engagement, innovation and agility.

Don’t forget to leave your comments below

 

The Great Facilitator Part 4: What Great Facilitators Know About Estimating

Written by Bob Zimmerman on . Posted in Articles.

Bob_Z_mar_27_28309844_XSIn my previous article, I shared an exercise that helps teams understand how to develop a plan that is manageable and achievable. I call this “Commitment-Based Estimation.” Now I will show how great facilitators can play a role in making their teams super confident about their estimates.

Who Should Facilitate an Estimation Session?

Before we talk about how to do a great job in facilitating estimation sessions, I’m going to discuss how to select the best person to facilitate these sessions.
I typically find that the Team Lead drives estimation sessions. Project Managers and Architects are also fairly popular in this role. The key, however, is to find a person who will allow the team to own the estimate.
When a Project Manager leads the estimation, they usually drive a team to develop estimates that reflect the project plan. Once the Project Manager starts imposing schedules, or challenges the team to optimize an estimate constantly, then the team won’t feel ownership. This is not how to get a Commitment-Based Estimate.

Similarly, when an Architect drives the estimate, they typically assume a technical frame of reference and try to help the team understand the mechanics of the estimation. If they impose their vision for the complexity of certain tasks, once again, the team won’t feel ownership.

So who makes the best facilitator for estimation sessions? I’d say look for a person who is:

  • Part of the team and has skin in the game
  • Already a respected leader and trusted by the team not to impose their personal views
  • Is experienced in helping teams balance risks, contingencies and dependencies

The One Rule You Should Never Break

There is one rule the facilitator must never break: Allow the team to come up with estimates they believe in. Unless the team is very junior or new to estimating, every team needs the freedom to come up with their own estimates. If the team asks for two weeks, never impose a shorter schedule and tell them to get the job done in one week.
Now you may be thinking: Does this mean I can never challenge a team? It does not. What it does mean is that as a good facilitator, you ask the right questions and help them share and test their assumptions.
For example, ask the team: “What would you need to get this done in a week?” or “How much can you get done in a week?” By asking the right questions, the scope may get reduced. Now you get the deliverable within a week because the estimation was not imposed on them. Again, the facilitator does not want to undermine the ability of the team to own the estimate.

Other Things Great Facilitators Do:

Some of the other approaches that have helped me personally manage some very strong groups include:

  • Make sure the team does not give an estimate that is simply unrealistic. I talked about this recently on my blog, in a post called “Attitude of Estimation.” As a facilitator, you want to encourage the team to come up with an estimate that is workable.
  • Ask questions and create assumptions to make the team think of scenarios that might happen. This helps the team create more accurate estimates.
  • Make sure everyone has a voice. Business Analysts need to be able to articulate the business needs and clarify what is being delivered. Project Managers can offer perspective on dependencies and resource availability. The QA team needs to test not only to see if something works, but also to see if the product is in compliance with business needs. Developers, Architects and the database team also need to weigh in. Too many times an estimate does not include a full set of voices and results in inaccurate estimates and mediocre functionality.

In my opinion, too many people take the facilitator role for granted. I think there are some jobs that are too important to perform any less than perfectly. Facilitation is one of them. A poor facilitator can break the spirit of a super talented team while a great facilitator can lead a good team to surprise itself on what it is capable of.

Get the whole picture by checking out the other 3 parts of this series –

Part 1 –  Part Business Analyst. Part Orchestra Conductor. Part Psychologist – Do you think of yourself as an effective facilitator but unsure how others perceive you? Maybe you’ve been at a meeting recently where the facilitator is doing a fantastic job but you just can’t figure out exactly she is doing differently. The differences are subtle.  This series is about those subtleties that separate the great facilitators from the mediocre ones.

Part 2 – Check in and the Chair:  Why can some facilitators effortlessly lead their team to achieve brilliant clarity and enthusiastic alignment? This article includes some basic practices great facilitators use to manage a room and deliver impressive results.

Part 3 – Commitment Based Estimation: In order for an estimate to have teeth, the team must feel ownership of the process and genuinely believe the estimates are achievable. This article includes exercises to facilitate estimates that are realistic and manageable. 

Don’t forget to leave your comments below.

Bob Zimmerman’s career in custom software development spans more than two decades and has been largely dedicated to the process of leveraging technology to drive innovation and growth. As Geneca’s CTO, Bob Zimmerman continues to build on his work as the driving force behind Getting PredictableS.M., the requirements definition and project best practices that are the foundation of Geneca’s mission to make software development predictable. He continues to extend these best practices to leverage more value for clients and new growth opportunities for Geneca.