Tag: Tools

Resources for the Investigative Analyst: Take your pick!

Written by Divya Kishore on January 14, 2021. Posted in Articles. 1 Comment on Resources for the Investigative Analyst: Take your pick!

Being a Business Analyst (BA) is a lot like being an investigative journalist.

You often must dig through lots of seemingly useless information to find the truth that can set you on the right path for your project.

Here are a few frequently overlooked items that you can utilize as resources and analyze to help uncover useful information:

1) Meeting Recordings: What can I gain by listening to a recording? Well, it gives you an opportunity to pause and think through:

What a stakeholder quoted?
What a developer suggested?
What a tester recommended?

These meetings can be analyzed and translated into process flows or current state diagrams. At the very least, by hearing a recording, you are now caught up with what was missed!

2) Presentations: I like to observe how slides are presented and structured during meetings. When slides have an organic progression of a topic, it is easy to follow along. When slides have too much information, I can get lost. Revisiting the slide deck after the meetings can help gain a better understanding of the topic or prompt you to jot down follow up questions. Analyzing the style or format of the slides that the author applied can trigger ideas or suggestions for your next presentation!

3) Email: Checking your inbox is like a daily chore in our professional and personal lives. What kind of analysis could I perform? Watch for those long email chains that includes all the back-and-forth conversations, they could be a potential input for Responsibility/ RACI (Responsible, Accountable, Consulted and Informed) matrix. Yes, it is exhausting to scroll all the way down, but it gives you an understanding of all the stakeholders involved and can provide a fuller perspective.

4) Notes: Missed attending a meeting? Missed recording a meeting? Notes can come to the rescue. Raw or clean notes, they are extremely helpful to get a coworker caught up or can be a memory refresher. In addition, notes can be a powerful input to build decision logs or can feed an action item tracker. Tada, now I know why we did what we did!

5) Chat conversations: I was working on a project one time and there was some confusion about the scope. I recalled I had a casual chat conversation a long time ago relating to the same project with the developer. I searched my chat history and bingo! I was able to pull up what we had chatted about. Fast forward…six months later, this back in the day chat helped the developer and I comprehend what was discussed in the past, what was missed in the previous release and perform a comparative analysis to identify the scope.

6) Artifacts: Grab a document or a diagram that was probably created by a team member or your peer. Study their style and how you can improve your next set of deliverables. Perhaps, it could be an eye opener to how one of the artifacts that you had authored in the past could have been trimmed down by replacing the written content with diagrams instead.

Conclusion:

Next time, when you are wondering, how to make information gathering more productive, I hope the above ideas can lend a helping hand and prove to be beneficial in your next investigation journey. Remember, it is the little things that can make a big difference or rather the little clues that can lead to the ultimate truth!

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.

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?

The Focused Analyst

Written by Anna Rajander on November 11, 2020. Posted in Articles.

Have you ever:

Started what you thought was a simple analysis task, only to find yourself unravelling a web of mystery?
Revised work that was completed early because things changed in the interim?
Suffered from Analysis Paralysis – continually re-analysed a situation instead of moving forward?

If you answered yes to the above, you’re probably a business analyst. So what steps can you take to promote the delivery of analysis that is relevant, has a clear purpose, and is available at the point-of-need? Perhaps there are some lessons to be learnt from agile delivery.

A distinction is often made between agile and “other” business analysis techniques. However, many of the techniques that are used to organise and prioritise work in agile projects can be employed more generally. This article summarises agile principles and techniques that can be used to plan work, manage stakeholder expectations, and focus on the delivery of real value – regardless of the delivery environment… agile, waterfall, other or undefined.

1. Definition of Done

The Definition of Done is a list of criteria which must be met before a work item (usually a user story) is considered “done.” In agile delivery, the criteria are agreed by the agile team prior to commencing work. Once a work item meets the criteria, it is considered done – and “done” means done!

The idea of “done” can be expanded to work performed outside of agile projects. Agreeing a Definition of Done with relevant stakeholders is a good way to set and manage expectations and identify priorities, prior to commencing work. This can promote more focussed analysis by providing a clear end-point, reducing the risk of both over-analysis and scope creep.

2. Relative Estimation

In agile delivery, effort is a relative measure. Effort is measured by comparing tasks and assigning points. Each task is assigned a single point value (usually a number from the Fibonacci sequence) individually by each agile team member to denote how much effort they believe the task requires. Tasks that are considered more onerous compared to others are assigned a higher number of points, while tasks that are considered comparable are assigned the same number of points. Where individual point values differ, the team discuss the reasons why to reach a consensus value. As tasks are completed over the course of an initiative, the actual effort-to-point ratio becomes apparent leading to more accurate estimates.

Relative estimation is useful as it is generally easier for individuals to predict whether a task will take more, less, or the same effort compared to another, as opposed to accurately measuring the time and resources required to complete a single task without comparison. Receiving estimates from multiple stakeholders/individuals is likely to result in more accurate estimates as additional variables may be considered. While it may take time to estimate enough tasks to accurately understand how points translate into actual effort, the result should ultimately be better, more reliable estimates for a range of work activities.

3. Just Enough, Just In-Time

As a rule, analysis and design activities in agile are performed on a just enough, just in time basis – just enough to not waste time conducting analysis and/or completing documentation that doesn’t add value, and just in-time to ensure analysis is current and available at the point-of-need.

Analysis is rarely done for its own sake – it is an input for further analysis, design and/or decision-making activities. Ideally, analysis work should be completed as-and-when it is required to ensure it is relevant. Focusing on why and when analysis is required provides a foundation for delivering just enough value-adding analysis, just in time.

4. Regular Reflection

In agile delivery, a retrospective is held at the end of every iteration. Agile team members reflect on the previous iteration as a way of learning lessons and implementing changes to improve the delivery process. Open and honest feedback is encouraged, and elicitation techniques such as Stop-Start-Keep, Affinity Mapping and Brainstorming are used to promote full participation. Because reflection happens regularly, the changes required to address concerns are usually small and/or incremental, making them easier for the team to implement and monitor.

While most project methodologies promote the logging and reviewing of lessons at fixed points in time, this often happens too late to be applied to current initiatives. The regular reflection and change promoted in agile has the benefit of allowing learnings to be applied early when they may be of most benefit to the initiative. Including regular retrospectives in normal work practices can be a good way of promoting and implementing continuous improvement.

5. Focus on Progress – Not Perfection

Agile focuses on making progress – not obtaining perfection. Agile delivery sets up a system that can respond to new information through iterative feedback and refinement. Work items are constantly reviewed and revised as new information comes to light. As work items are completed, they are made available to stakeholders who are encouraged to provide feedback. It is generally accepted that initial versions will not be good enough, but that open and regular reviews will provide the information required to make them acceptable.

There are some simple steps for promoting the principle of progress over perfection in everyday business analysis. Set expectations early – never promise perfection. Engage stakeholders regularly – multiple short, sharp engagements can be more productive compared to longer one-off meetings. Focus on analysing what is important. Produce deliverables in a format that supports regular updating. Where possible, create “living documents” that are updated as-and-when information becomes available. Don’t be afraid to present work that may be incomplete or incorrect – showing the wrong answer can be an effective route to right answer.

Conclusion

Many of the principles and techniques associated with agile delivery can be employed in business analysis more generally. Pigeonholing techniques into “agile” and “non-agile” may mean suitable analysis techniques are overlooked. The principles and techniques that help agile teams organise and focus on delivering can assist in the delivery of timely, value-added analysis – regardless of the delivery approach.

Resources:

The Agile Samurai: How Agile Masters Delivery Great Software, Rasmusson, Jonathon, 2010.

Agile Alliance – Definition of Done, https://www.agilealliance.org/glossary/definition-of-done, accessed October 2020.

Toolbelts in Times of Change

Written by Kristen Gandier on August 27, 2020. Posted in Articles.

The kinds of organizational, environmental, and personal shifts that happen during changes on the global scale are both long-lasting and far-reaching.

A thorough approach is needed, not only to consider all impacts but also to plan the path of success.

Business analysts can leverage specific approaches during times of significant change to help an organization put its best foot forward and effectively arrive on the other side of transformation.

Adapt with Tools and Techniques

Business analysis tools and techniques that were successful in one circumstance may not be the ones best suited to a new environment. For example, the recent global pandemic reveals that many organizations are suddenly faced with having to forge new paths through uncharted territory in a technology-based virtual landscape. Meeting rooms, face-to-face interviews, and lunch workshops turned into IM chats and video conference calls while juggling pets and children in the virtual professional world.

When left a new environment, a first impression may be one that sees a large number of limitations. The reality though, is that business analysis has many prescribed techniques that can be leveraged in a way that promotes elicitation and collaboration to thrive.

Explore the tools and technology available in your organization and it may be found that workshops can be easily adapted to video conferencing, where presentation software can still be used through screen sharing, where content does not require a great deal of edits. Understand the difference that a virtual environment provides, and you may find that brainstorming sessions may help typically shy stakeholders feel more comfortable participating in a call-in style dynamic, where they may not feel as “on the spot”.

Teams Move Mountains

The year 2020 saw many professional landscapes change. For many, physical buildings, water coolers and coffee machines turned into laptops, video conferencing, and screen sharing. Keeping stakeholders and project teams engaged with so much personal distraction is a delicate balance, but during such a significant global event, changing networks can create new meaningful connections. For example, individuals all balancing different personal lives and home situations may lead to changed work hours, which may shift team dynamics. Look for new ways to carry networks and connect with teams. Differing schedules may create ad-hoc availability and facilitate the possibility for an unstructured interview with a key stakeholder, where a typical schedule would not have allowed.

Keeping teams engaged through the current state while projecting a future state amidst significant personal distractions takes a great deal of resiliency and organization. With some strategy and planning, the virtual environment can be one that allows for new meaningful connections with stakeholders, organized execution of goals, and winning arrivals at deadlines!

Allow team dynamics to have organic and healthy changes, and understand that these shared and lived experiences can add to cohesion, communication, and trust, which are all important characteristics of successful teams!

The Bigger Picture

Change is normal. While professionals are always encouraged to understand the inevitability of change and transformation, circumstance adds a factor that can magnify the impact and see the change as daunting and stressful. This is where conducting gap analyses with forward-thinking approaches can set the tone for initiatives of all sizes. Staying on course with momentum when considering current and future states can not only keep progress timely but can keep a change strategy effective. Stay on track of taking steps forward, even slower paced ones at times, and it will soon be found that you and your team are achieving the higher hanging fruit.

Changes during Changes

The world is a dynamic, fluid, and inconsistent experience. Keeping these few things in mind and approach can help transition yourself and your enterprise through the winds of change to a successful outcome:

Leverage your environment
Strength is in numbers
Keep your eye on the ball

The probable can be planned – the improbable is not usually part of the plan, but can have a significant impact. Keeping your professional and personal tool belt well-equipped with adaptable techniques can help yourself and your teams move toward that gold on the horizon.