Tag: Requirements

What does success look like?

Written by Melissa Anstedt on December 30, 2020. Posted in Articles.

I like to challenge Business Analyst to look at requirements as an opportunity to define what success looks like for the requestor.

Too often teams fall into a trap focused on prescriptive requirements that are to serve as a roadmap for developers and testers to know what to build and how to make sure it is working. When you start viewing requirements with this prescriptive lens you lose sight of the overall objective and stifle creativity that comes from meeting problems with fresh solutions.

Why do we need requirements?

Requirements are the union between the customer and the solution. They define expectations and how to meet them. Requirements illustrated through user stories or through waterfall documentation play a large role in helping shape technical solutions and the steps it will take to implement. They also lay out the acceptance criteria and use cases for said requested change. This leads to creation of test scenarios and the ability for the team to sign off and say, “yes this is what I requested. It checks all the boxes”.

But what if we offered more with our requirements. What if we could connect those requirements to broader objectives that the customer is trying to solve? What if we could get requirements in such a way that could lead to solutions to problems, they maybe never realized they had? These solutions could ultimately lead to increases in productivity, profits, and/or customer satisfaction. When you shift the mindset that requirement gathering sessions are to get “technical specifications”, to an opportunity to learn about a problem and bring it back to the group for a creative solution; meaningful technical solutions begin to emerge that are readily adopted by users and integrated into processes.

How do I make more out of requirements sessions?

When I was early in my career as a business analyst, I would leave requirements gathering sessions and think, “How am I supposed to do this, when the users don’t even know what they want?”. This usually came from an approach that looked something like this:

Me: “So let’s talk about what “xyz” will look like and what it will do”

Them: “Well I won’t know what it can do until you build it”

There came a point when I realized, that it isn’t the customers job to know how to give me requirements. These requestors represent a segment of the company and were hired to be the best accountant, lawyer, analyst, etc. It is my job to know how to elicit requirements, and sometimes it will require some creativity and perfectly placed questions to make the most out of my requirements gathering session.

Requirement Elicitation

The best questions to use in a requirement gathering session are those that create dialogue and conversation. The more people are talking about a requested change, the more information can be gathered by the Business Analyst to bring back to the developers/testers for a solution. Even better than a rousing conversation, is a moment of silence. If you can ask a question to the customer that causes them to stop and pause and say something like ‘I hadn’t thought of that before”, you have asked a great question. These questions cause people to think through exactly what it is they are looking for and more importantly how it will look if it is successful, and how they will ultimately adopt said change.

Here is a sample of these types of questions that can be used to really drive at sound requirements, that will ultimately lead to technical solutions that users adopt.

If this project/enhancement does not happen, what would be the impact?
Is there anything in this process/system that you would not change?
If this system/change looked exactly how you pictured it, what would the process look like? How would you interact with it?
What would be your best measure of success?
Why do you think we need ”xyz”? How did we get here?
What have you tried in the past?
What are the top problems/challenges that your business faces? Why?

Finding the right time to ask one of these questions takes practice, and there is no better time than now to start!

What Use Case to Use?

Written by Jenny Quillian on December 9, 2020. Posted in Articles.

The Use Case is a standard tool in the BA toolkit, and like most tools they come in different shapes and sizes for different jobs.

During Business Analysis Planning it is important to identify the appropriate use case format for the project needs. At the high end we have a multi-page highly regulated requirements template. The base model is a single actor and basic flow. Between these is the textbook version with complex flows. This article looks at these use case formats and design influences to consider during your Business Analysis Planning.

Use Case Formats

Simple Flow Use Case
Complex Flows Use Case
Highly Prescribed Use Case

Simple Flow use cases describe the interaction of a single actor along one basic flow. This format can be used as the starting point for a more complex effort, as a placeholder for planning purposes, or as the final deliverable for a simple project. This format is similar to a user story, with post conditions instead of benefits.

Complex Flow use cases include alternate flows, triggers, business rules, post and exit conditions. The degree of complexity should be determined by the stakeholder needs and perspectives. For business users the documentation must be readable so that they can follow and agree that you have captured their needs correctly. For the architects and developers, the details must be specific enough to translate into units of development. For the testing teams the documentation must provide clear inputs and outputs of success so that they can formulate test cases.

Highly Prescribed use cases have a multi-page template with approved instructions to complete each section. There are projects which require such discipline, but I have also worked on projects where the template became the end rather than the means, and the degree of detail slowed down the project and produced wasteful documentation.

Design Factors

Use Case formats will be influenced by:

Funding model
Requirements complexity
Rate of change
Regulatory environment
Project methodology
Project phase
Build or Buy

Funding Model

Organizational funding models may impose a need for provide for detailed requirements well in advance of the project development phase, in order to compete for funding. A use case that identifies all potential steps, alternate flows, business rules and usage estimates can be useful to assist with cost estimates. Tight funding oversight models will ask for more detailed documentation than open models.

Requirements Complexity

Retail web pages for major sellers can be large and complex because of the product offerings, but the system requirements themselves are repetitive and reusable and changes easily delivered with a user story or simple use case.

A new system with complex requirements needs more detailed documentation than an informational web page. A new system with many business rules needs detailed documentation and requirements tracing to ensure proper coverage. Integrated systems need a degree of rigor ad traceability to ensure that front end changes do not break upstream or downstream systems such as integrated re-order or delivery systems.

Rate of Change

The retail web pages are repetitive but require rapid changes to meet demand and marketing plans. The requirements documentation cannot stand in the way of rapid delivery.

From another perspective, detailed requirements documentation that can be reviewed in the change management process can help slow down a rush delivery and prevent embarrassing releases.

Regulatory Environment

Systems that are governed by external regulations need detailed requirements documentation that can be read and understood by multiple stakeholders so that all affected parties are able to understand and approve the inputs and outputs of the system to be delivered. Systems that collect personal information must be able to demonstrate that the correct information is being captured and the appropriate security will be in place to protect this information from misuse.

Project Methodology

Waterfall projects tend to require detailed requirements. Agile projects prefer minimal documentation, user stories, and simple use cases if any.

Project Phase

Documentation detail may expand or contract during the project phases. As discussed above, projects may require detailed requirements documentation for early feasibility and cost analysis exercise, but they may then drop down to user stories for the development and delivery. Other projects may require only simple use cases to outline a concept, and then expand on the use case flows and details during the requirements phase.

Build or Buy

If the project includes a build or buy decision, then a simple use case format that can be transferrable to a matrix of acceptance and evaluation criteria will be most useful when comparing solution options.

Summary

Use Cases are a valuable business analysis tool that come in multiple flavors. As part of the Business Analysis Planning step the Business Analyst should identify the degree of rigor and detail that the project and the stakeholders require and select the appropriate use case format(s) to use during the project.

Taking responsibility for the outcome

Written by Shane Turner on November 25, 2020. Posted in Articles. 1 Comment on Taking responsibility for the outcome

As a Junior Business Analyst who’s about to go into a meeting to report on why our latest deployment into production had so many bugs –

it made me think about all the missed opportunities and potential questions I could have asked myself to catch them sooner.

As a business analyst, it’s my job to brief the team on the features that need to be developed, and ensure they get the designs and documentation to ensure a smooth, (hopefully) bug-free implementation that can be thoroughly tested before release. So why did we have four bugs then?

Assume responsibility

Asking yourself these questions may help to pinpoint where the issue originated:

1. How often are change requests initiated (not due to a change in business requirements), within the project – due to incomplete or incorrect requirements?

2. How often are bugs added to the backlog, as a result of unclear or misunderstood requirements?

How often are the designs or documentation being updated to re-clarify the requirements which have been misunderstood by the developers?

How often are the testers missing potential test scenarios due to lack of knowledge of the scope of the work being implemented?

How often are additional backlog items and stories created due to lack of completeness within the specifications?

How often does the client point of missing aspects of features or stories which have made their way into the staging environment or production due to a poorly fleshed out requirements spec?

(Less) Consistency is key.

I found myself answering ‘frequently’ to too many of the above questions, which not only impacts the overall deadline of the project, but it also costs our clients a fair penny in project costs.

Striving to be a better BA does not mean perfection from day 1, but rather small improvements over time – and that means starting with an honest reflection of where you may be falling short.

Don’t fall into the blame game of, “Oh, but the developer should have thought of this scenario”, or “Oh the testers should have picked it up”. You created the spec, you were there for the grooming, and the planning – and had the opportunity to glance over the test cases before development began. Take ownership of the outcome.

So where did I fall short this time? Even though my spec was well thought out AND I provided the testers with a list of test scenarios to consider, the one thing I didn’t do – was consider the scope of the system being impacted in the development -resulting in an entire segment of the system going untested.

Sometimes we’re so focused on the little details that we forget to take a step back and take in the bigger picture.

The Modified Design Sprint: Simplifying a Tried and True Brainstorming Method

Written by Charis Horner on November 19, 2020. Posted in Articles.

Facilitating team brainstorming is a key skill for BAs in product development. How can we generate innovative, divergent, and executable ideas that meet customer needs?

Jake Knapp, John Zeratsky, and Braden Kowitz dove deeply into this problem and gave a beautiful gift to the BA community: The Design Sprint. (You can read all about it here.) The Design Sprint is a four- or five-day brainstorming session, with structured activities and outcomes taking a team from a big problem to a tested solution.

But what if you don’t have five days? What if you need to make a major decision and you need to do so… now? My team faced this very question and created a new version of Knapp and Co.’s game-changing process: The Modified Design Sprint.

What is the Modified Design Sprint?

The Modified Design Sprint (MDS) applies tools from the original Design Sprint to team brainstorming and decision making on a smaller scale. It uses timeboxing, collaborative ideation, heat map voting, and Decider overrule to mine information from team member’s brains and create a shared understanding. While the original Design Sprint ends with a tested prototype, the MDS gives the team prioritized, Decider-approved, team-backed ideas for further development – and it can be done in as little as an hour!

When should I use a Modified Design Sprint?

You may want to consider using an MDS when:

An effort has a lot of unknowns
You need answers to questions or solutions to problems from a diverse set of people
The team has a lot of competing ideas and you need to pick a lane
There is a lot of work that could be done, but you need to quickly prioritize the most important things

How do I carry out a Modified Design Sprint?

Fear not: The MDS requires only slightly more legwork than a typical meeting – and yields more quantifiable results.

Assemble a team

First, pick a Facilitator. This should be someone good at getting to the root cause, directing conversation, and asking open-ended questions. (Hint: It’s probably you, the BA or PM.) The Facilitator ensures the team accomplishes its goal.

An MDS is not a democracy – it’s a benevolent dictatorship, so you need a Decider. This person can ratify or veto decisions. It might be the CEO, Product Owner, or Team Lead. The MDS empowers the Decider to make fully informed decisions on key issues, emboldened by the team’s expertise.

Round out the team with anyone who has an important perspective for your effort, like other BAs, marketing professionals, developers, researchers, and designers.

Define the Goal and Questions

A successful MDS begins with a clear purpose. Are you trying to prioritize system functionality? Determine the MVP for your product? Decide on a solution for a proposal? The Facilitator and Decider should draft this goal before the session.

Once the goal is defined, you need a list of Sprint questions that represent decisions to make, customer needs to meet, problems to solve, or any other area where you want diverse team input.

Set the Agenda

Once questions are decided, the Facilitator should create a timeboxed agenda. This suggested agenda for a 60-minute session leaves 5 minutes to add wherever the team needs more.

Set the stage (10 min)
Draft Ideas (15 min)
Review Ideas (10 min)
Vote (10 min)
Decide (05 min)

Do the Prep Work

The Facilitator needs to get the room set up before the MDS. There are plenty of virtual tools for this like Miro, Mural, and FunRetro. In an online tool, set up each of your questions as a column, with sticky notes in the rows below. If you’re in person, you’ll need sticky notes, pens, expo markers or voting dots, and a whiteboard. Write the agenda, goal, and questions on the board. Here’s an example of an MDS board in Miro:

Set the Stage

Begin the MDS by reviewing the agenda, sprint goal, and explaining the Facilitator and Decider roles. Then review the question list and ask if anything is missing. If there are blind spots your team was hoping to solve, now’s the time to identify them.

Draft Ideas

Silently, everyone takes their sticky notes and answers the questions on the board. The Facilitator should give time reminders so that team members stay on track.

Review Ideas

This part is tricky; the goal of reviewing ideas is not to determine their value, but to ensure they are understood by the team. Read each sticky note out loud; if anyone needs clarity, they should speak up. Once clarity is achieved, move on to the next sticky note. For the sake of time, the Facilitator should (nicely) jump in if the conversation begins to derail. The next step will allow everybody’s voice to be equally heard.

Vote

This is where the magic happens. It’s time for the team to decide which ideas should rise to the top. There are two approaches to voting:

Heat Map: Each person has an unlimited number of total votes but can vote on each idea up to 3 times. This turns the board into a “heat map”, as the best ideas will have the most dots on them.

Tough decision: Set a voting cap, such as 3 votes per column, or 15 votes for the whole board. Each person can only vote on each sticky note once.

Decide

Using the team’s votes as a guide, the Decider looks at each column and picks the ideas which MUST be included. Most Deciders pick the highest voted items, but they can choose other items they believe are necessary. Selected ideas become the “winners” for further development. Unselected ideas can be typed up, tabled, and revisited at another time. Now you’ve got clear direction on key ideas for success.

The MDS can simplify brainstorming to quickly give the team a path forward in difficult ideation areas. Ready to try it?

Minimum Viable Product (MVP) Released: Move on or Resume?

Written by Divya Kishore on October 21, 2020. Posted in Articles.

What’s next? If you are like me, then you are pondering the next item on your to-do list and you can relate to this question.

I end up planning for the next task while my current one is still in progress. Typically, a multi-year project is broken into phases. Prior to the completion of the first phase, discussions are already under way for the next phase. As humans, it is natural to get excited about the new features in an application and want to continually improve on those features. Yet, it is worthwhile to take a pause from “What’s next” or “What’s new”, so that the team can reflect on parking lot items and lessons learned to help define product value.

Here are a few action items that a Business Analyst (BA) or any team member can resume post MVP release:

Revisit the user’s wish list: I have worked on initiatives where we got so focused with the delivery of MVP that the immediate next step was to continue to improve the released MVP. In this process, the wish list of the end users or “nice to have” requirements that were tabled were permanently left off.

How can I help? Record, revisit and re-evaluate wish list items on the backlog once the dust settles down with the MVP release. Follow up discussions relating to these items act as a reminder and help discover new backlog items.

Address edge cases: Recall exceptional scenarios that came up in previous meetings? Often, these exceptions do not transpire on a regular basis and end up on the back burner because the goal initially is to just rollout the MVP.

How can I help? Schedule a discussion, create a project plan and address the one-off scenarios. Risk and prioritize these scenarios to determine which ones will be in the next MVP release and which ones will potentially never need attention.

Reiterate “New functionality vs value”: I was shopping online once, and the website met all the primary needs of an online shopper. However, it was when I had entered all the payment information, I was notified that an item was not in stock. As an online customer, I see more value in receiving live inventory updates for an item instead of the fancy features offered on the website. From the vendor’s perspective, MVP release could be “complete”, but did anyone analyze and evaluate what is truly valuable to an online customer?

How can I help? Perform value analysis. Collaborate with the business partners to define “value”. Value may look very different from the lens of a manager vs the lens of an end user.

Update glossary: I have attended meetings where participants call out terms and abbreviations. When it is a global project, there is an extra layer of chaos since there are a myriad of words and languages thrown all over the place. A lack of standard global terminology is an ongoing problem.

How can I help? Volunteer to author this list and get the definitions reviewed by business partners. Maintain a glossary as a living document in a central repository where everyone can review it after every MVP iteration.

Gather feedback: Are the users inundated with the new application or functionality? Are they forced to adopt the new application? Do they feel it is the same way of doing business but in a new application this time?

How can I help? A survey is a great option to capture the true sentiments of a user. It gives them an opportunity to vote on their likes and helps the team determine value for the next MVP release.

Have you resumed tasks that were placed on hold due to the MVP release? What are the action items you would like to pick up from where you left off? Think about it!! You do not want to keep improving the last MVP endlessly and overlook the features that never made it to the MVP release. The end goal is not to get so absorbed with the MVP that the tasks or action items post MVP release slip through the cracks.

“Strive Not to Be A Success, But Rather to Be of Value” – Albert Einstein