Tag: Requirements

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

The Unbiased Analyst

Written by Anna Rajander on August 13, 2020. Posted in Articles. 3 Comments on The Unbiased Analyst

Whether it be interviews, surveys or questionnaires, business cases, observations, or root cause analysis – any technique can introduce bias into a business analysis initiative.

Bias can result in the collection and synthesis of erroneous information leading to the delivery of sub-optimal, discriminatory, and/or inadequate solutions. It is therefore important that Business Analysts are aware of the different types of bias and the risk they pose to any analysis.

The following outlines some common forms of bias, as well as provides some simple approaches for mitigating the risk of introducing bias into an analysis.

Selection Bias

In cases where there is a large group of stakeholders, it is often not practical to elicit information from every individual. Instead, information is elicited from a selection of group members.

Selection bias is where individuals are more or less likely to be selected from the larger group. The risk posed by selection bias is that the information solicited from the selected individuals is not representative of the larger group.

Any business analysis technique that involves selecting individuals to represent an entire group is at risk of introducing selection bias. For example:

Surveys and questionnaires often depend on individuals taking the time to respond, which may be depended on a range of variables, including being aware of the survey/questionnaire, having access to complete the survey/questionnaire, having the time to respond, and/or having the ability to respond.
Interviews usually involve selecting individuals or asking for volunteers from a larger group.
Observations may introduce selection bias based on when and/or where the observation takes place.

It is also important to be aware that any elicitation that involves self-selecting is inherently biased towards those who chose to be involved.

Response Bias

Response bias is a general term that accounts for range of bias that influence the response of participants away from an accurate or truthful answer. Some areas that may contribute to response bias include:

Recall – human memory can be unreliable, particularly if the information being recalled is complex, regards an event that took place a long time ago, or involves information that may be considered traumatic.
Perception – this is where a response is influenced by what is perceived as a ‘good’ or ’bad’ answer. The responder essentially changes their response or behavior based on what they think the interviewer/observer wants to hear/see, ultimately leading to the collection of erroneous information. An individual’s response can also be impacted by how a question is framed. For example, using overly negative language, positive language, or language that is associated with a particular ‘side’ can influence response.

Any business analysis technique that involves collecting information direct form stakeholders may be at risk of introducing response bias.

Personal Bias

Personal bias is where an individual unintentionally or unwittingly introduces unwarranted opinions and feelings into a situation, making objective opinions difficult. Business Analysts are at risk of introducing bias into an analysis because of their own views and believes.

Some particular areas of personal bias include:

Observer Bias – this is bias introduced when an individual’s point of view or understanding impacts how they perceive a situation. For example, an observer may misinterpret a situation because the language used has a specific meaning in the given context that the observer is not aware of.
Confirmation Bias – this is the tendency for an individual to seek out evidence that confirms their own personal views, while downplaying or discounting evidence to the contrary.
Overconfidence – this is where the credibility and/or knowledge of an individual or source is overestimated.

Introducing personal bias into analysis is a risk for any Business Analyst regardless of the technique being used.

Avoiding Bias

The following is a non-exhaustive list of ways Business Analysts can mitigate, counteract or avoid introducing bias into analysis:

Understand your stakeholders – take the time to understand your stakeholder groups, including understanding attributes that may impact the particular needs of individuals within a group. Attributes to consider include demographic information such as age, geographic location, socio-economic status, and/or access to technology. Techniques such as stakeholder maps may assist in identifying attributes and decomposing stakeholders into more relevant sub-groupings.
Don’t rely on a single technique – when eliciting information from a large population of stakeholders, consider using multiple techniques across non-mutually exclusive groups. For example, follow-up surveys with interviews, consider confirming results from an observation using a follow-up questionnaire etc.
Support with hard evidence – where you are soliciting complex or historical information from stakeholders, confirm with hard evidence wherever possible, such as using emails, audit logs, meeting minutes and/or policy documents.
Census, not survey – where possible and practical, consider making responses to surveys and questionnaires ‘compulsory’, essentially turning them into a census. This approach can also be applied to interviews and observational studies where a stakeholder group is small.
Use advisory groups – where available, include advisory groups, unions, or other available advocacy group in your elicitation exercise to represent stakeholders. Advisory groups are more likely to have in-depth knowledge about a stakeholder group that may allow them to identify areas analysis may have failed to address. Advisory groups may also be useful when validating the findings of an elicitation exercise and understanding if further elicitation is required.
Understanding the context – take the time to understand the full context of the situation you are analysing, including the terms, acronyms and phrases that have a specific meaning to stakeholders. Consider keeping a glossary of terms and making sure it is validated by stakeholders to ensure language isn’t taken out-of-context.
Be self-aware – take the time to reflect on your own personal perspective and how it may influence your analysis. Where you are aware of a personal bias, consider finding and confiding in a colleague who can critique your approach to ensure it remains unbiased. Consider removing yourself from initiatives where you have a clear conflict of interest.

Conclusion

Bias is a risk to any business analysis initiative. However, with a little planning and self-awareness, any risk of bias can quite easily be mitigated or avoided.

Getting Requirements Right with KickOffs and Desk Checks

Written by Maria Rios on July 16, 2020. Posted in Articles.

Have you ever been at a restaurant and received something different than what you ordered?

I’ve had unwanted sour cream on my nachos and swiss cheese in my omelet instead of provolone. Even if it was close to what I requested, I often returned my food to the kitchen to get it fixed. Waste of time for both me and the cook, not to mention I would be hungry by the time I got my food.

A similar experience has happened to me with software development. As an Agile organization, we regularly hold lead reviews and story grooming sessions. Despite numerous meetings, I sometimes found myself in a situation where what a developer coded is not exactly what I asked for. How is that possible after hours of discussions? The answer is simple. Human nature. What one hears may be interpreted differently by someone else. Memory isn’t always reliable for stories reviewed a few days or weeks before. Also, until a person is the one working on a story, he/she may not be listening 100 percent during team activities.

As any developer and QA engineer can tell you, building something that doesn’t match the requirements requires rework and retesting, which impacts a team’s ability to meet sprint commitment. So how can we minimize wasted time? My department has adopted the following practices which have reduced the botched order syndrome significantly:

Story Kick-Off
Story Desk-Check

Story Kick-Off

A story kick-off is done prior to coding to ensure that the developer, QA and the BA/Product Owner are in alignment regarding expectations. Asking the following questions helps to ensure a successful kick-off.

Are the requirements clear?

As the BA, I review again all assumptions, the acceptance criteria and any supporting documents, such as UI and report mock-ups. Everyone’s memory is refreshed, and the opportunity exists to answer questions and to ensure everyone is on the same page. In addition, the wording within the story may be modified or additional notes added to provide clarity.

Do we have all the technical tools and information needed to finish this story?

Our developers perform preliminary investigation prior to a kick-off to determine what is needed from a technical aspect. When issues affecting completion of the story are identified, negotiations around requirements commence. For example, we may find that a new function cannot leverage existing code as initially anticipated. I often ask whether the extra effort can be absorbed in the current story without impacting timelines. The outcome may involve conversion of an acceptance criteria into its own story or pulling the story from the sprint altogether for additional refinement.

Are there any blockers?

We normally identify story dependencies ahead of time and plan sprints accordingly. Due to resource constraints, we sometimes find ourselves playing blocking or dependent tasks within the same sprint. If called out during kick-off, it reminds us to coordinate activities across the team to help ensure timely completion.

Will assistance be needed from other departments in order to complete coding or testing?

If yes, we like to inform those groups at kick-off, so they have a few days to plan accordingly. As an example, we may need DevOps to bring a connection down to test failure scenarios.

Story Desk-Check

A story desk-check is performed when coding is completed but not yet pushed to a test environment. The participants include the same people involved with the initial kick-off. Activities include the following:

The developer demos the functionality that he/she has built while cross-checking against the requirements of the story.

Have all the acceptance criteria been met? Does the output, such as UI screens or reports, match the mock-ups? Are any bugs encountered during the demo? If identified at that time, the developer can more easily fix issues in their local environment before it even gets to QA. Problems found sooner contributes to less bug finding during testing which equates to time saved.

Provides the opportunity to tweak a requirement.

A demo sometimes identifies requirements which sound good in theory but does not work well in reality. For example, we may find that an error message that I’ve requested is hard to see. I could ask that the error be moved to a more prominent location or be highlighted in red. If the impact to the sprint is small, the developer and QA can agree to the modification and the story is updated. For larger efforts, I create a new story to be placed in the backlog and prioritized.

Helps QA prepare for test execution.

The developer provides input on how a story can be tested. Are there tools available to help them verify the data? What configuration or setup is needed prior to testing? Impact to existing functionality is also called out so that they can be retested to ensure nothing is broken by the new code.

Other groups participating in the desk-check, such as DevOPs, become aware of when their assistance will be needed and can schedule their time with QA.

Two years after initial implementation, kick-offs and desk-checks continue to be an important part of our development process. It is extremely satisfying to see how minutes invested up front saves us from hours of rework later. There’s always room for improvement, but in the meantime, I am happy to say that what development now gives me is usually exactly what I ordered!