Author: Angela Wick

Brainstorming: We have lots of ideas, now what?

Written by Angela Wick on May 12, 2014. Posted in Articles.

In the world of business and technology, success stems from good ideas. Successful organizations rely on a variety of idea generation techniques to:

Solve problems
Identify options, needs and features
Improve processes
Resolve issues
Create or modify products

Teams assume good idea generation techniques inspire collaboration, creativity and innovation, but struggle to transform those assumptions to reality. They don’t find the promised value in their brainstorming sessions. Instead, meetings end with stakeholders buried in piles of sticky notes wondering where the value is hiding.

Stakeholders forget that idea generation is only the first step—maybe the easiest step. Piles of sticky notes and rolled up flip chart sheets don’t offer value on their own. We need to find a way to process the output of your brainstorming session until a clear path to value appears.

Process the output: divergent and convergent thinking

Good idea generation techniques require divergent thinking where all participants submit new ideas and expand existing ideas without criticism, constraints or editing. Words like impossible, impractical, stupid, too expensive do not exist in this divergent process.

This process makes some team members uncomfortable. BAs need to let visions of business rules, risks, process diagrams, and system constraints fade away. Concerns about scope and cost do not apply in this open brainstorming phase.

(Some companies use squirt guns to quiet people who critique divergent ideas.)

After the divergent phase, the real work begins. How do you process the ideas? How do you narrow them down to something tangible and valuable? Here are a few possibilities for the first convergent thinking phase:

Condense-remove duplicates, group similar ideas
Categorize-Often categories or themes emerge that can be an umbrella for multiple ideas
Matrix-Ideas may fit into a matrix like SWOT (strengths, weaknesses, opportunities, threats) or high/low cost vs. high/low time, high/low benefit vs. high/low complexity
Range/Scale-List ideas in order by feasibility, practicality, cost, time, impact or value.

A clear path: prioritization

After the initial convergent thinking phase, an idea prioritization process provides a clear path to value. There are many ways to prioritize a list of ideas and the proper technique will vary depending on the nature of your ideas, but here are three suggestions:

Voting-Allow participants to vote on their favorite ideas virtually with a survey tool or in-person with tallies or dot stickers. Consider the value of anonymous voting. Consider allowing more than one vote. Consider allowing no votes and yes votes.
Buy a Feature – a prioritization technique that allows stakeholders to vote and prioritize with “play money”. Encourage customers to pool their money to buy important/expensive features. Need an online/virtual version? Buy a Feature
Forced Ranking – Place two ideas/features in front of the group, ask the group to decide if the second idea goes above or below the first. (Ideas at the top of the list have the highest priority.) Then take the third idea, ask the group if it goes above, below or between the others. Continue through all ideas until they are ranked in order.

Finding value: taking action

The prioritized list of ideas should offer a clear path for action.

If the list includes new features for a product, the team might start defining requirements for the top features.
If the list includes solutions for a problem, the team might attempt the solutions in order of priority until they found success.
If the list includes ideas for process improvements, the team might begin process change procedures for the top requirements.

When working through the priorities remember to check-in with stakeholders to reassess. New priorities might be added and existing priorities might shift. Also, remember to celebrate success!

A note about stakeholder buy-in

In many cases, project managers and business analysts find it difficult to get stakeholders to participate in structured idea generation processes. We’ve all been on projects where solutions come before requirements, where collaboration is not valued, or issues are ignored.

BAs promote project activities that boost sponsor value. Find ways to educate stakeholders about the benefits of divergent thinking. If all else fails, find informal ways to gather ideas. Try to inspire divergent thinking by asking questions like:

How might we…?
What would that look like?
How could you modify that idea?
What if we can’t do that?

Over time, as creativity and innovation grow, your stakeholders will begin to see the value of brainstorming. Be patient as you build trust.

How do you gather and process ideas?

Don’t forget to leave your comments below.

The Devil is in the (Non-Functional) Details

Written by Angela Wick on April 14, 2014. Posted in Articles. 92 Comments on The Devil is in the (Non-Functional) Details

Some systems are a joy to use. Others create extreme frustration and waste valuable time. Why? What’s the difference? Well, let’s think about the characteristics of good and evil systems:

The “angels” of systems are:

intuitive, easy to use
fast
reliable, always up and running
error free (mostly)

The “devils”:

frequently down
glitches kick you out and force you to login multiple times
lock-up and cause you to restart your computer
can’t easily customize your user experience
poor help features
not intuitive, hard to use, hard to find what you need
processing time is slow
doesn’t work on mobile devices

It’s not that the devils lack key features. In fact, the devil systems have great features we want to use, but we can’t access them. These frustrating systems waste our time. Our complaints trace back to missed or incorrect non-functional requirements (aka: quality of service requirements or supplementary requirements).

The challenge I will put out to you, ask your stakeholders and users what they don’t like about the system . . . they will likely tell you all about the things they don’t like and these are likely missed non-functional requirements. Our stakeholders, users and even ourselves take for granted and assume the non-functional aspects of systems.

Protecting Value

As a BA, your job is to protect value—to ensure that business sponsors get the results they expect. While you identify needs, define features, write use cases, uncover business rules and manage issues, don’t forget about the non-functional requirements!

Missing non-functional requirements can:

Increase project risks
Dramatically reduce stakeholder value
Limit the productivity of internal and external users
Create foundational defects that are difficult and expensive to fix

Defining non-functional requirements

Non-functional requirements:

Describe the constraints or quality of the service/system/process/product as a whole or
Describe constraints or quality measure of individual features or requirements.

Common categories of non-functional requirements include:

Security -What requirements are needed to prevent misuse, keep unintended users out, authenticate users, keep data confidential to the appropriate users and non-users, and which actions can be taken by which users?
Usability-Is the solution understandable to users? Do users intuitively know how to perform the action they want? Are there sufficient help resources or easily found contacts for help?
Reliability & Efficiency-When does the system need to be available? What is needed to recover from errors effectively? What is the acceptable time for the system to perform certain functions?
Transferability-Can the solution be used in other environments–technical or business? Does it need to be?
Maintainability-What are the requirements around the ease of modifying the solution? How easy is it to add rules and logic, add users, change a component without impacting others?
Compatibility-What other application, systems and solutions does the solution need to operate with?

Non-functional requirements example

An example always helps right? So, let’s use Angie’s Pizza Shoppe. They make most of their money delivering pizzas to busy downtown office workers during lunchtime. They want implement an online ordering system to minimize order errors and create efficient lunch delivery service. Check out these non-functional requirement examples:

Non-Functional Requirement	System or Feature Level
The system shall provide a way to recover/view orders when the system is down	System
Scheduled system downtime should be between 3AM and 7AM.	System
The time it takes a user to place an order online should be equal or less than the amount of time it takes to place a phone order, which averages 5 minutes.	System
Credit card numbers should be hidden from all internal users except the general manager.	Feature
When entering credit card information the system needs to return an authorization/approval of valid card to the user within 10 seconds of submitting.	Feature
The system should work on mobile device platforms (Apple, Android) as well as desktops and laptops.	System
Angie’s Pizza Shoppe toppings vary by season. Internal users need to be able to modify the topping list daily, without a system release.	Feature

Documenting non-functional requirements

Obviously, requirement deliverables vary widely across projects and organizations, but you need to find a way to:

Elicit non-functional requirements from stakeholders
Review/prioritize non-functional requirements with stakeholders
Share non-functional requirements with sponsors, developers, testers, etc.

When determining the best way to document non-functional requirements for your project, remember that some will trace to the whole system and some will trace to features, user stories, or individual requirements. You might “document” the non-functional requirements by:

Creating a separate non-functional requirement document
Adding them to your requirement list denoting NFR in the “requirement type column”
Listing them at the end of each use case
Adding them to your user stories acceptance criteria
Communicating these requirements verbally to the developers on your team
Listing them on your process models and flow charts

Let’s not create devilish systems by ignoring non-functional requirements at the system whole or feature levels. Don’t assume your developers and testers understand system constraints or quality measures. Let’s be mindful of the value non-functional aspects of the solution bring to our users and stakeholders.

Don’t forget to leave your comments below.

Three BA Metrics You Should be Tracking

Written by Angela Wick on March 18, 2014. Posted in Articles. 2 Comments on Three BA Metrics You Should be Tracking

What do you know about healthcare.gov, the United States’ new online healthcare marketplace? No matter your political affiliation, you have to admit the launch of the website has been a giant fiasco.

When you visit the site, here are a few of the interesting things you might experience:

A waiting line. Yes, just like the Department of Motor Vehicles —If the system is busy, you will be put into a queue and have to wait before you can begin the application process.
No mobile capabilities, you need to use a desktop or a laptop for best results.
Great advice like: “If you’ve created an account previously and have had problems with it, create a new account with a new user name, email address, and password. Be sure to clear your cookies and cache before you create your new account.”

I am fascinated by this very public debacle. My BA curiosity kicks in and I want to know:

Is it possible to have a smooth launch of a large, complex project with dozens of vendors trying to integrate project plans, requirements, designs, systems, etc.?
Who decided to launch a broken system and what was their rationale? Did anyone advocate for prototyping, a pilot program or a phased approach?
Is it faster and cheaper to launch a flawed system that needs several months of repairs or spend years trying to get the system right before launch?
What skills or tactics could we use to prevent similar problems with our projects?

As our friends at Healthcare.gov repair, update, and maintain the healthcare marketplace, it seems likely they are tracking hundreds of standard metrics like number of applicants, number enrolled, number of defects, system downtime, system error rates and response times.

These metrics are important and offer a great snapshot of the current state of the system. Trend lines for these metrics might help you with system troubleshooting or system risk management strategies.

However, these system-focused metrics don’t offer insight to improve project management or business analysis processes. They don’t help you assess the value of the BA role or track stakeholder satisfaction.

Though you may not work on complex, high-profile projects like healthcare.gov all BAs, need to evaluate and improve their processes. Here are three metrics that help BAs gauge their effectiveness, value and efficiency:

1) Layers of Defects

Can you imagine the size of the defect log for a system like healthcare.gov?

As time passes, most large systems develop layers of defects. A project goes live with 10 defects. The fixes for those defects result in more defects, and so on. How many layers deep are your defects and missed requirements issues?

When I work with organizations and BAs, I establish this metric by asking, “What originated this work?” for every project/enhancement/bug fix. I often hear one of the following:

“It’s from another enhancement that did not work out right.”
“It’s a new requirement for a project that went live last month.”
“This fixes a defect from a project that went live last year.”
“This addresses issues from another defect that we misunderstood.”

Then I ask again, “What originated this work?” I get the same responses. In many cases, I ask this question multiple times and find more than FIVE layers of defects hiding under each project.

I am finding that many organizations spend 80% of their time and money working on projects that are essentially rework—features and functionality that originated from missed requirements, misunderstood requirements, poorly tested requirements, etc.

This never-ending maintenance work indicates weakness in requirements processes. The rework hogs resources that would be better spent on innovative and strategic capabilities.

Tracking the layer of defects or the percentage of work being done to fix something broken or missed will help organizations gauge the health of their BA and even testing processes. BAs should use this metric to determine how to “get it right the first time” and free up resources that will offer more strategic value to stakeholders.

The balance to this metric is if you are expecting rework that is due to an agile approach where the rework is really learning and discovery and part of the process. In this case, rework for these projects should be removed from the metric.

2) Business Sponsor’s Percent of Successful Projects

The definition of success varies from project to project. When I think about healthcare.gov I can imagine many different definitions of success:

Project team: “The system will be delivered on time and under budget.”
Consumers: “I want the system to be like the amazon.com of healthcare.”
Democratic Party Leaders: “I want the system to help us secure the presidency for 8 more years.”
Republican Party Leaders: “I want the system to fail miserably to help us secure the house, senate and presidency.”
Media: “I want the system to cause controversy so I have news to fill my 24-hour cycle.”
People who already have good healthcare insurance: “What system?”

BAs need to consider the definition of success from multiple perspectives. But whose perspective is most important?

When I ask leaders of PMO offices what percent of their projects are successful, they typically reply with an answer between 80-90 percent. When I ask the business sponsors the same question, time and time again I hear that only 20-30 percent of their projects are successful. Funny isn’t it?

PMO: 80%-90% of our projects are successful
Business Sponsors: 20%-30% of our projects are successful

So, I ask how they measure it?

PMOs often measure by cost and schedule
Business sponsors measure by: “Did I get the value I expected based on the money I paid?” or “Was the project worth doing—is my life better?”

The BAs primary job is to identify and protect the sponsor’s value proposition, so the success metric needs to be driven by the sponsor’s perception of value. It’s critical to the requirements and BA role.

In many cases, BAs need to set time and budget aside and work based on value.

In some cases value will conflict with time and budget (Ahhh, yes, healthcare.gov!). When you recognize this conflict, you need to partner with the PM and/or sponsor on your concerns.

How can BAs drive this success percentage higher?

Understand what outcomes the sponsor values most and why.
Look for inconsistences between the sponsor’s expectations and the project team’s expectations?
Determine how to prevent inconsistencies.
Determine how to front-load the value—give your sponsor value ASAP.

3) Rework Caused by Diving Into Details Too Soon

OK. I am dragging you back to healthcare.gov one more time. I can’t begin to imagine the pressure analysts in this environment felt as they began to outline requirements! I can only assume that SME resources were extremely limited and tight deadlines caused BAs to choose a path: all details or no details.

Based on my experience, most analysts on intense, complex projects jump directly from a high-level business need or scope document to the nitty-gritty details. They feel crunched for time or have limited access to resources, so they gather and document as much detail as possible without leading stakeholders through the big picture.

This nose-dive to details seems efficient, but usually results in and unmanageable amount of rework as the project progresses:

You may have trouble completing deliverables as you need to re-write when you are still eliciting.
Traceability becomes complicated and gaps arise when detailed requirements do not have connections to higher-level features or processes.
Change control becomes a nightmare if you add design details to requirements documents. The design will change after your requirements document is base-lined, creating a change control headache for you with each update.

So ask yourself:

How much time do I spend rewriting or updating requirements?
Do I rewrite because of new things I learn during the elicitation process?
Do I rewrite because of enhancements and defects?

Then, improve your rework metrics:

Complete higher level modeling and requirements ahead of details.
Capture details informally, but don’t add them to official project documents until higher level models are approved.
Avoid managing traceability and change to a level of detailthat will change (i.e. screen designs)

Great BAs know how to guide their stakeholders through a progressive elicitation process that moves from concepts to details. They manage rework and change control by understanding when and how to offer details.

Which metrics do you find most valuable and why?

Don’t forget to leave your comments below.

User Stories and Use Cases – Don’t Use Both!

Written by Angela Wick on March 4, 2014. Posted in Articles. 18 Comments on User Stories and Use Cases – Don’t Use Both!

We’re in Orlando for a working session as part of the Core Team building BABOK V3 and over dinner this evening we got to discussing the relationship between user stories and use cases (it wasn’t the only thing we discussed, we are also a social group ;-)).

We noted with concern that there have been a number of recent discussions (client, articles, blogs and general industry) of using both User Stories and Use Cases at the same time in Agile projects. This seems to us (with general agreement around the table) to be both a waste of effort and actively against the Agile philosophy of doing the simplest thing that will work and deferring the detail until just ahead of when the component of the product will be built.

We would like to outline the basic differences, considerations and risks of using this approach. Even it is seems to be a trending topic, we would like to fill the gap in addressing beyond the trend and move towards the practically and risks of using Use Cases on Agile projects.

Differences and Similarities

So what are the differences and similarities between User Stories and Use Cases, and when do we recommend using the different tools?

Use Cases

A Use Case is “an end to end sequence of interactions between an actor and a system that yields a result of observable value to an actor, usually the instigating actor”. Um, so what does that actually mean? Generally a Use Case (the textual description, not the stick figure diagram) is written as a flow or sequence of steps in the format

Actor does something
System does something
Actor does something else
System does something else
…

A Use Case is made up of one main flow and a number of alternate and/or exception flows some of which can branch back to the main flow.

Now Use Cases are by nature fairly detailed – they describe the steps in an activity and the points in the flow where things can change. To produce a useful (can be given to someone to build from) Use Case you need to define the set of interactions in quite a bit of detail, you need to understand what the business rules are that govern the activity, the options that the actor will have available to them when undertaking the activity, the ways things could go wrong and what bits of information are needed in the flow of interactions. To do this you need to spend quite a bit of time and effort analysing the activity and producing the document. This is BDUF – Big Design Up Front which is the antithesis of Agile.

User Stories

User Stories were originally a reaction to this big up front thinking. When Kent Beck defined eXtreme Programming (XP) he came up with the concept of a User story as a tool to support the iterative and incremental approach which is inherent in all the Agile methods. Mike Cohn went on to write a book which explained what User Stories are and how they are used in Agile projects. In addition to these two, Jeff Patton publicized the technique of Story Mapping to show how User Stories can be used to cover the breadth and depth of functionality needed in a product.

The key to writing good User Stories is to understand that the intent is not to provide the detail early on in a project, but to provide a framework where the detail can be added as it is needed, just enough and just in time. Drawing on the work of Beck, Cohn and Patton and many others the generally accepted approach to producing User Stories and using them to guide the development of the product follows a decomposition approach.

The decomposition comes in the form of a story map. The beginning of a story map is defining the Backbone stories – the key User Activities or Tasks which need to be accomplished to do the work of the product, the large discrete chunks of functionality which need to be delivered to be able to say we have solved the problem. These large chunks are often referred to as Epics (a big story ;-)), they equate to an elementary business process, something that is done in one place, at one time, by one person. Comparing this to Use Cases, this would be the result of the Use Case survey – a list of the discrete elements of the product, goals of the actors.

When building a story map, these Epics are normally laid out in a single row showing the logical sequence and handoffs between the steps in the process. Visually these Epics will be written on a different colour card to t e User Stories which will come later.

Image: An Example of a Story Map – Epics in green along the top

Epics can be put in sequential order along the top (if sequence is appropriate, which it normally is).

The next step in the Story Map is to populate the map with the User Stories that fall under the Epics. Each User Story is a small, discrete piece of functionality that has value to some user of the product and is a decomposition of the Epic above. The most common format for writing User Stories is “as a (role) I want (feature or capability) so that (business value to be delivered)” –

As an internet banking customer I want to list my account balances so that I can understand my financial position.
As an internet banking customer I want to list transactions on an account so that I can check the detail

The three elements are important – knowing who the story is for helps ensure we build a useable product, what the functionality is that is needed and the value which will be derived from having that functionality enable us to make good priority decisions.

Priority based on business value is very important to defining User Stories. Knowing the value from a story enables us to make good decisions about the sequence of work – building the most important business value components first and getting feedback early rather than trying to build everything at once is inherent to Agile.

The User Stories are the orange cards in the image above.

Priority and Sequence Shown in the Map – identify the MVP

One of the benefits obtained by building a Story Map that shows the logical flow of activities (from Epic to Epic along the top) and the discrete elements of those Epics vertically down the page is the ability to clearly see both sequence and priority. Stories that are higher up on the map are more important (needed sooner) than those lower down.

The prioritisation and sequencing approach enable the discovery of the Minimum Viable Product (MVP) – those elements which need to be delivered to provide the opportunity to learn and adapt the product based on feedback from real customers/users. Finding the true essence of the product and getting that into the hands of real customers (probably just a small subset initially but enough to get feedback to validate the assumptions being made in the development of the product).

In a real-world internet banking example, the very first version of the product which was put in production had the ability to log in and to list balances and this version was used by the project team and a small group from within the bank. Having this “walking skeleton” built and put into production validated the architecture of the product, identified a number of unexpected challenges with the deployment process and gave the team feedback about their design philosophy which enabled them to make some significant changes when they were cheap and easy to do.

The Elements of a User Story

In his book, Mike Cohn says that a User Story has three C’s – the Card, the Conversation and the Confirmation. The Card is the initial User Story, written on an index card or PostIt note. This is deliberately short and devoid of detail. The intent is to defer the detail until later in the project, just ahead of when this piece will be delivered. The detail is established through the second C – Conversations. As the project progresses and elements are delivered there will be a number of conversations that result in clarity of understanding about what is actually needed to deliver the value identified in the User Story.

The final C is Confirmation – these are the Acceptance Criteria for the User story – the details which will enable the customers and the technical team to agree that “if this story meets these criteria it is done”. This is the detail which is all too often left out in bad Agile projects (“Tragile”). This detail needs to be agreed to, and it will contain whatever is needed to enable the delivery of this component of the product. The key difference between Agile and other approaches is when we produce this detail. In an Agile project this will be produced collaboratively with the customer representatives just ahead (a couple of hours to a couple of days) of when the piece will be built.

The most common format for these acceptance criteria is the structure of Acceptance Test Driven Development. Each user story will have a number of acceptance criteria and may also have other elements which will help ensure the right thing is built – these could include screen mockups, technical notes, models such as class diagrams and whatever the team needs to enable them to deliver the business value.

Examples (for the list account balances user story)

Given the customer has one credit account and one savings account
When they have logged in successfully
Then the two accounts will be listed in account number order (Account no, Name, Balance, Available Funds)

Given the customer has no accounts
When they have logged in successfully
Then a message indicating that there are no accounts to show will be displayed

Given the customer has twenty one accounts
When they have logged in successfully
Then the first twenty accounts will be listed in account number order
And a Next Page option will be enabled

Given the customer has twenty five accounts
And they have logged in successfully
And they are on the first page of the list
When they activate the Next Page button
Then the list will be cleared
And the list will be populated with the last five accounts
And the Previous Page button will be enabled
And the Next Page button will be enabled

Gojko Adzic’s book Specification By Example provides an excellent reference on how and when to produce acceptance criteria.
Ultimately the Acceptance Criteria will be proven through a set of test cases (ideally automated) which show that the product works as needed to deliver the business value.

Reduce Waste and Be Responsible

Again, the key to reducing waste and rework is to defer this detail until just ahead of when it is needed, rather than trying to clarify it all up front. Things will change over the life of the project and deferring the detail makes it cost-effective to adapt to this change.

However – taking this just-in-time approach is not an excuse for poor architecture or bad design. Early on in the product development it is important to set clear architectural guidelines, design principles and deal with what Philippe Kruchten calls the “Architecturally Significant Non-functional Requirements” – those aspects which will be extremely expensive and difficult to refactor later. Note however that we say “guidelines” and “principles” – don’t try to build the complete architecture up front, allow it to be emergent inside the boundaries of these clear guidelines.

Traceability in User Stories

Hopefully it is clear from this description that User Stories actually have a powerful traceability mechanism built into the design of the technique.

There is a cascading one to many relationship:

A Role or Class of User derives value from one or many Epics
One Epic could have many User Stories
One User Story will eventually have many Acceptance Criteria
One Acceptance Criterion will have multiple Test Cases which prove it is working as expected

This traceability is enacted through the “so that” component of the user story, which ensures that every piece which is implemented has a direct relationship to the business value to be derived from that component/capability.

Timing Makes the Difference

The key is the timing – User Stories are deliberately abstract early on in a project and will evolve over time on a just-in-time and just-enough basis. This is because Agile projects expect and anticipate change and respond to this change by adapting the product to the evolving needs. More User Stories will be added, some will be dropped and our understanding of many will change as time progresses. The reality of today’s business world is that change is inevitable, so trying to define the detail of all aspects of the upfront will result in lots of wasted effort and time as much of the work will need to be redone.

The Story Map is a fluid and changing tool – as stories are completed they are removed, new ones added and change is accepted as a normal part of the way we maximise the delivery of value to our stakeholders and the organisation for whom the product is being built.
The detailed Acceptance Criteria for any User Story will on be produced just ahead of when it will be delivered, maximizing the amount of work not done (one of the 12 principles of the Agile Manifesto)

One of the mistaken and dangerous myths of Agile is that “Agile projects have no documents” – the reality is Agile projects have the documentation that is needed to ensure value is delivered, and nothing more. The philosophy is to defer work until just ahead of when the output of that work is needed (a concept inherent in Lean thinking) and only do that work which is necessary to achieve the desired outcome (preventing waste from unnecessary effort and rework).

This is in stark contrast to Use Case thinking where the goal is to define in the various flows of the use case all the detail of the requirements up front. This approach will inevitably result in wasted effort as the use cases will have to be maintained and updated as the changing needs emerge. In agile we want to evolve the solution iteratively and incrementally as we learn based on feedback from real customers/users, not rework the documentation and requirements.

Could you use Use Cases instead of User Stories in an Agile project?

Theoretically Yes – you could indeed use Use Cases instead of User Stories to express the business needs. None of the Agile approaches are prescriptive about how you express the list of capabilities/features the product must contain (what Scrum calls the Product Backlog), however we see significant risks in trying to do so. Use Cases miss the mark on the “WHY”; they are not well suited to expressing the separate pieces of business value and supporting the iterative, incremental approach to developing the product – they tend to be monolithic and encourage an “all or nothing” way of thinking vs. an adaptive evolutionary style of learning and discovering the solution together through quick build and feedback loops.

Could you build Use Cases after developing an Agile solution to document the requirements after the fact?

Theoretically, yes . . . however with this approach you have missed out on a critical technique in User Stories to guide conversations towards maximising value and minimising extra work throughout the development process.

Risks and Dangers of Use Case Thinking in Agile Projects

Compromised Innovation
- Use Cases bring on a lot of detail before getting feedback on a built product. This cognitively brings user mind-sets into a predefined interaction and solution, negating the potential for further innovation. The exploration and learning aspect is compromised and focus goes from solving a need to perfecting an already defined solution.
Compromised Timelines:
- Too much detail before building compromises the benefits of time in the Agile approach. Spending time detailing out Use Cases is spending time on what and how when we be should focusing on the why. Defer the what and how until just ahead of when it is needed
Compromised Value:
- Use Cases confuse the role of Acceptance Criteria in User Stories and agile. Many teams are using Use Cases as an alternative to creating Acceptance Criteria for their User Stories. Acceptance Criteria evolve in levels of detail as builds iterate and evolve and more is learned together through the agile process. This learning process is where the value lies as the needs are quite unknown before starting.

Conclusion

Many teams embarking on their Agile journeys are finding comfort in techniques used in the past for requirements definition, particularly Use Cases. Use Cases resemble user stories in more detail, and User Stories were developed as a condensed technique to alleviate the lack of WHY in Use Cases and to alleviate too much detail too soon when using an Agile approach.

We believe that User Stories and Acceptance Criteria are the techniques aligned to deliver the benefits of the Agile approach and Use Cases compromise and put the benefits of the Agile approach at risk.

Teams thinking about using Use Cases should strongly consider looking at the methods and evolutions of defining Acceptance Criteria (especially the model) with many scenarios and levels of detail that evolve as feedback through the iterative cycle and delivering increments of the product as it evolves. Keeping with user stories (Including story maps & epics) along with well defined and evolving acceptance criteria will meet the goal of leveraging the benefits of agile without putting timeline and value at risk.

Don’t forget to leave your comments below.

About the Authors

Shane Hastie

Shane is the Chief Knowledge Engineer and Agile Practice Lead for Software Education, a training and consulting organisation based in Australia and New Zealand, working all around the world.

Shane teaches courses and consults around business analysis and agile and is passionate about bringing the two communities together.
He is a member of the board of the Agile Alliance, and is the lead editor in the Process and Practices community on InfoQ.com
He can be reached at [email protected] and on twitter as @shanehastie

Angela Wick, CBAP, PMP

Ms. Wick is passionate about inspiring innovative BAs and is a leader in the business analysis field. Angela is a trainer of business analysis, project management and in bringing innovation and creativity to these roles. She enjoys working with traditional and agile teams, and especially in preparing teams for agile in their organization. She also consults with organizations in building BACoEs, BA practices, BA Career Models, and BA competencies. Angela is a lead contributor to the BABOK v3 and the IIBA Competency Model. Angela is also a monthly blogger on BaTimes.com

Angela can be reached at [email protected] and on twitter @WickAng

Both Shane and Angela are Core Team members for the IIBA team building version 3 of the Business Analysis Body of Knowledge (BABOK)

Get Fit: Lose the Business Analysis Weight

Written by Angela Wick on February 18, 2014. Posted in Articles. 1 Comment on Get Fit: Lose the Business Analysis Weight

Many of us started 2014 with a stack of goals and resolutions. Did you resolve to take a few pounds off by eating healthier, hitting the gym, or running a 5K?

What about your professional health and fitness? Do you have a few extra professional pounds dragging you down?

Some BAs are lugging a spare tire around their middle—outdated techniques or broken relationships hold them back from becoming their best professional selves.

So, let’s lose some BA weight and build strength, increase flexibility and improve efficiency. Here are a few ways to work smarter not harder in 2014.

1. Strengthen or Rebuild your PM relationship

BAs have many important relationships to manage, but the relationship with the PM might be the most important. The best BA/PM combos are true partnerships.

Sit down with your PM and discuss requirement process goals and improvements for 2014. Tell the PM what s/he can expect from you that is different, new, and improved. Explain what you need from the PM to support these goals.

Foster this partnership throughout the year:

Establish consistent communication channels: set up a weekly status meeting, touch base over coffee or lunch, create brief summaries of key meetings and share them, and/or create a visual, one-page BA dashboard that gives up-to-date status of your deliverables.
Find common goals and work together to achieve them. Figure out how to make each project successful and how to add value to your organization.
Solve problems together. When complex project issues arise consult the PM. Share information, strategize and collaborate.
Understand ALL potential project risks—not just BA tasks—so you can look out for your PM’s interests. Be the eyes and ears of the project team.

2. Trim the details

Scale back on details that are of minimal value. For every document, every presentation, every e-mail—ask yourself why each detail is important. In many cases, excess details blur the big picture. Stakeholders with a blurry big picture are a major risk to a project. This lack of context will cause way more pain than missing details.

When peers ask for feedback, clarify the type of feedback they want. Don’t focus on grammar details and typos when they ask for content and contextual feedback.
Review emails before sending. Is the length appropriate? Do you use bullet points and white space effectively? Are you asking for too many things from a really busy person in an email? Is e-mail the appropriate tool for the information you have to share? Would a call or meeting be more effective?
Review your documents before distributing. Are you creating documents full of details and sending all the details to everyone to review? Consider your audience. Does everyone need all that detail? Are there ways to effectively summarize the information? Can you add visual elements that provide context for your stakeholders? Can you decompose the information so it is easy to follow for everyone?

3. Kick your meetings up a notch!

Evaluate your facilitation toolbox. Toss those old tools and find a few new ones. You’ll see huge benefits in efficiency when you learn how to make meetings fun, collaborative, and valuable for everyone. Here are a few tips:

Determine what each stakeholder will learn or get from your meeting.
Keep the invite list as small as possible. Meaningful collaboration happens in small groups.
For workshops—plan activities elicit information strategically rather than just asking, “What are your issues?” or “What are the requirements for this feature?” or “What is the best way to fix this?” It’s highly unlikely these canned questions will produce creative or complete responses.
Make meetings engaging. Don’t sit around a conference room table for an hour. Get moving. Use whiteboards and Post Its. Find creative ways to elicit ideas or prioritize requirements.
Virtual Meetings-Multitasking is bad enough in person, but it’s usually worse on conference calls. (You’ve heard dogs barking and kids crying and toilets flushing right?) You have to encourage active participation, beyond just listening. Engage the eyes and the hands. There are so many tools out there, many of them free, that help BAs create interactive virtual meetings. Try virtual whiteboarding, virtual Post Its, virtual breakout sessions or virtual facilitation games.
Make them fun, collaborative, and with value for everyone. What will they learn or get from your meeting?

So, take a risk in 2014. Drop the dead weight and try a new technique, build stronger relationships and question the details. Assess your best practices and find efficiencies. Flex your BA muscles!

Don’t forget to leave your comments below.