Tag: Best Practices

Seven Common Mistakes with the Daily Stand-up Meeting

Written by Greg Smith on December 18, 2012. Posted in Articles.

The daily stand-up meeting, also known as the daily scrum, may be the best of all of the agile practices. Why? Because it meets three criteria:

1. It’s easy to start using
2. It can often be used without other agile practices
3. It provides great value

Stand-ups can be interjected into waterfall teams and they can be used without converting to iterations or other common agile practices. From an adoption perspective, the resistance to using stand-ups is low. From a value perspective, teams quickly see the how the stand-up identifies risks and issues early. The stand-up gives them more time to react and still hit their goals.

As good as the stand-up meeting is, if done incorrectly it can do more harm than good. As an agile coach I have found I often skimp on stand-up training because it seems so simple. But this skimping has come back to bite me several times. How have I been bitten? By the seven common stand-up mistakes below.

Mistake # 1 – Not Standing (the daily sit down)

Teams usually stand when they first start doing the daily stand-up because they have just came out of agile training and they were taught to stand. But as time progresses it is common for some teams to assume standing is a formality and they start sitting more and more. This especially common if the meeting is in a conference room where chairs are available.

Standing is not a formality but rather a key success factor in establishing collaboration and keeping the meeting short and effective. How can you keep the team standing? Here are some tips that usually help:

Try to do the stand-up where chairs are not available.
Keep the team focused on the three key questions: What did you do since we last met? What will you do between now and the next meeting? Do you have any blockers or constraints that are impeding your progress? It is common for team members to explain their impediments in detail, and for a dialogue to start up between a few team members on how to resolve the impediment. This is fine if a solution is agreed to in a few seconds, but usually this a long conversation that ties up the whole team when only a few team members are needed. So as a Scrum Master, coach, or team member, get select team members to work impediments together after the stand-up.
Use a physical status wall (covered in mistake # 5 below).

Mistake # 2 – Team Members Not Showing Up On Time

Many teams struggle with team members drifting into the stand-up, often 5 to 10 minutes late. This contributes to the issue noted above, not standing, but also demonstrates a lack of personal discipline. Here are some tips for addressing the late arrival issue.

Pick a time of day that the team all agrees to, to have the stand-up. Sometimes management will ask the Scrum Master to have the team meet at a certain time, but I have found it is better to meet when everyone has arrived at work, and at a time the team all agrees to.
Get support from line managers. Agile is about team self-management and self-discipline, but everyone does not arrive at this state at the same time. If you are a Scrum Master, work with all of the managers who team members work for, and get agreement that the daily stand-up is important, and that punctuality is important. Line managers can emphasize these values when they do one on ones with their team members.
Provide a buffer between meetings that occur before the stand-up. If there is another meeting that precedes the stand-up, make sure the stand-up is not scheduled when the other meeting ends. Instead add a buffer of 10 to 15 minutes so that the stand-up is not impacted by any upstream meetings that runs over.

Mistake # 3 – Allowing Distractions

Daily stand-ups are ineffective if the team is not focused during the stand-up. Here are some tips for keeping the focus:

Location, location, location. If you do your standup meeting in the wrong location the team will get interrupted by passers by, or be distracted by eye candy such as the street below. Pick a location without chairs, some level of isolation, and if possible no windows.
Set a team norm of no cell phones or laptops during the standup.
Focus on good meeting etiquette – no side conversations or whispering.

Mistake # 4 – Updating the Project Management Tool During the Stand-up

Are you using an online tool to track project status? Maybe Mingle, Rally, or VersionOne? Many times the team will stand idle while someone is updating the tool during the stand-up. Try to avoid this at all costs. Have someone take hard copy notes and update the tool later, or even better, use a physical status board and have team members physically update their tasks during the daily stand-up. Remember that the tool serves the team, the team does not serve the tool.

Mistake # 5 – Not Using a Physical Status Wall

I love electronic project management tools. They let me consolidate information and do reports across a portfolio of projects. But the tools can impede collaboration during the daily stand-up. If one person is projecting the virtual status wall from an electronic tool, and discussing it with the team, the team often becomes an audience and just listens. However, if you have a physical wall with task cards, team members move and update their physical cards during or before the stand-up, which leads to much richer discussion and interaction. You can use an electronic tool in parallel (most of my clients do). It may be a little redundant, but the value a physical wall provides offsets maintaining 2 tools. And it will lead to a better stand-up meeting.

Mistake # 6 – Not Having a Dedicated Team Room

You may be wondering why you need a dedicated team room for a stand-up. You do not need a dedicated team room for the stand-up meeting, but you do need one for a good stand-up meeting. Confused? Here is the scoop. If your team is distributed all over your campus, and they come together physically each day for 15 minutes, do you think you can get them to only discuss status? I have not been successful in doing this. Developers and testers will want to get into testing details during the stand-up, user experience wants to talk to developers about screen details, and so on. If you have a dedicated team room, team members can talk about the construction details all day long, and they will not need to deviate from the stand-up status/impediment discussion.

Mistake# 7 – Not Using a Stand-up for Distributed Teams

Most companies I work with have team members in the United States, India, and China. These teams will often tell me they cannot do stand-ups because everyone is in different time zones. I understand this issue but I also understand that we undertake a lot of risk if we do not communicate daily. To get around this issue I have teams do the following:

Do a stand-up meeting at each location. At a minimum get team members synchronized at each site
Have one team member from each team work a staggered schedule. These team members on staggered schedules can do a video call or audio call to synchronize each day, and then take that information back to their local teams.
Use electronic tools to share status details. Electronic tools really show their value with distributed teams. Everyone can see the status information around the world, as soon as it is entered.

Follow these steps and you will establish a sound daily stand-up process, which will provide a great foundation for all of the agile practices you use with your team.

Don’t forget to leave your comments below.

“I Said My Name Is . . .”

Written by Angela Wick on November 20, 2012. Posted in Articles. 1 Comment on “I Said My Name Is . . .”

After several years of experience as a business analyst you begin to see examples of good and bad business analysis everywhere you look: your bank, city hall, the IRS, your grocery store, your cell phone company, etc. We are all end users, customers and consumers.

For better or worse, business analysis collides with many aspects of our personal lives.

Over the course of the last few months, I have been in a fierce battle with bad business analysis—all because of marriage and moving. These are two relatively common life events. Name and address changes should be simple, standard processes. And yet, most organizations fail to successfully manage changes to basic customer data.

My battle started when I realized, after the wedding was over and the witnesses had left the state, that there was an error on the marriage license. My new name was incorrect. I filled out the application properly, but the data on the application did not transfer correctly to the license. A process failed.

Eventually, the marriage license problem got fixed, which allowed me to get an updated driver’s license. Three months later, when I went to vote on Election Day my name on the voting registry was incorrect. It matched the erroneous name from the original marriage license. Now, my ID and voter registration, created by the same organization, did not match! A process failed.

My favorite airline was the source of my next skirmish. In order to get through security, the name on my airline ticket needed to match the name on my driver’s license. My license was “in progress” which means I had a piece of paper instead of the card. Surprisingly, a simple phone call can get tickets re-issued with a different name.

The process to update a frequent flyer account is more complicated—requiring a copy of my marriage certificate and an updated passport or driver’s license. (So no proof needed to change the name on a ticket to fly, but two legal documents needed to help me earn points and get my bags checked for free. Hmmm?)

So for my honeymoon flight, I had to pay for my bags because the frequent flyer name and ticket name did not match, and the documentation needed to get them to match was “in progress”.

The main issue is that the two processes are not connected. I can change my name on my ticket, but until the long frequent flyer change process is complete, I miss points, bags, and upgrades. Ugghh! A process failed.

Once I got the airline situation under control, bad business analysis continued to bombard me via the daily mail. Despite my effort to comply with each organization’s change process, the mail continued to arrive with a humorous variety of names and addresses. My favorite mailing included an envelope, a form letter and a check. All three pieces of the mailing had a different combination of name and address. Many processes failed.

So messing up a name or address change is frustrating and inconvenient, but what if bad business analysis leads to financial loss for the business or customer? What if my financial information, accounting transactions, purchase order modifications, invoices were incorrect?

The quality of an organization’s business analysis affects its bottom line. Understanding and communicating the links or disconnects between policy, procedure, and systems is what gives you value as a BA. BAs prevent risk. BAs minimize loss. BAs prepare organizations to change successfully!

So how can good BAs prevent failed processes and negative customer experiences? Here are a few suggestions:

Create an Event/Response Matrix

An Event/Response Matrix identifies external, internal and temporal events and what happens to the process or system when the event is triggered. If “name change” is an identified event, then analysis would be completed to understand what would happen when “name change” is triggered.

Event/Response Matrices help BAs discover issues and reduce the risk of missed or assumed requirements. “Name change” is a perfect example of assumed requirements. Stakeholders tend to focus on the new features of a system specific to their line of business and often assume that we understand requirements for standard tasks that span the enterprise. We must look “outside-in” with requirements, looking at events outside of the products, systems and business processes; evaluating the impact.

Find the Duct Tape and Bandages

Every organization has duct tape and bandages—little manual processes or databases or spreadsheets or macros that meet a business need but have not been integrated into formal procedures, policies, or systems.

The duct tape and bandages were applied to the business for many different reasons. The primary reason: good leaders found a way to do something cheaper, faster, better while wading through the red tape of official policy or system change.

Identifying and understanding these obscure workarounds can be critical to the success of the organization. We need to evaluate these disconnected practices and determine if they need to be integrated into projects. We need to understand the risks and rewards to determine if the practices should continue or be shared with other parts of the organization.

Understand Interfaces

BAs need to understand how systems share data. Even an informal interface assessment with stakeholders can uncover requirements and minimize project risks.

A few good questions to ask yourself or your stakeholders about interfaces during the elaboration process:

Where else do we use this type of data?
Are there existing interfaces between all of the systems?
Does the current interface meet the business need?
How does data transfer between systems?
How do these systems get updated with new data?
How frequently are changes updated?

Learn About Data Management Strategies

Among other things, a data management strategy defines how an organization moves, integrates, maintains, audits and archives data that is used enterprise-wide.

Does your organization have a data management strategy? Is it comprehensive? Do people actually use it? Is it up-to-date?

Most likely, you will find an answer of “no” or “not really” for at least one of the questions above. So you need to investigate and understand the informal, unwritten data rules in your organization. It is likely these rules will vary across the organization.

So many systems get built and updated without looking at data migration, external events, and the customer experience. BAs add value to the organization when they can anticipate and communicate data management inconsistencies.

Be a Data Integrity Advocate

Given the fact that most companies do not have an effective data management strategy, BAs are left to help business leaders understand the pitfalls of bad or out-of-sync data.

Inform stakeholders how bad data negatively impacts the customer experience and the bottom line. Guide them through decisions about value, risk, and impact.

Today, I am still working through name change processes and resolving errors of the processes I thought I followed correctly! As frustrating as it is, ironically I was in a recent requirements workshop where this exact scenario came up. The discussion evolved and this scenario became a low priority requirement. Why? The volume of customers that get married and move at the same time in a given year is pretty low and the impact and risk to customer value is relatively low. I understand this, and to be fair to my profession, I must conclude that bad data and process is at times the right decision when we must balance value, risk, impact and budget.

Have you bumped into bad business analysis in your day-to-day interactions with companies and organizations? How would you prevent or fix the problem?

Don’t forget to leave your comments below.

Use Case Preconditions: A Best-Kept Secret?

Written by Willem Van Galen on October 16, 2012. Posted in Articles.

Introduction

Alistair 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.

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.

Conditions enable loosely coupled use cases

What is loose coupling again?

Two use cases are loosely coupled when:

The execution of the first enables the execution of the second.
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.

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, 12^th 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 October 9, 2012. 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.

Alternate Flows

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.

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.

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.

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 May 28, 2012. Posted in Articles.

In 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.