Tag: Methodologies

Empowering Your Scrum Team: Why Developers Should Own the Sprint Backlog

Written by Aman Fogat on July 25, 2024. Posted in Articles.

In my seven years as a Business Analyst, I’ve worked with numerous Scrum teams across various projects. One issue that I’ve repeatedly encountered is the confusion over who owns the Product Backlog versus the Sprint Backlog. This misunderstanding often leads to inefficiencies and tension within the team. Through my experiences, I’ve come to realize the importance of clearly defining these roles to ensure smooth and successful project execution.

In the dynamic world of Agile development, Scrum stands out as a framework designed to promote collaboration, flexibility, and continuous improvement. However, even within this well-structured framework, misconceptions can arise, particularly regarding the ownership of the Product Backlog and the Sprint Backlog. Clarifying these roles is essential for any team aiming to harness the full potential of Scrum.

The Core Misconception

During Scrum training sessions, particularly with teams that have prior experience, one topic often sparks intense discussion: who truly owns the backlogs? The common but flawed practice is for the Product Owner to decide what work the team should pull into a sprint. While this may seem like an efficient approach, it fundamentally misinterprets the roles and responsibilities within Scrum.

Understanding the Roles

The Product Owner is tasked with maximizing the value of the product by managing the Product Backlog. This involves understanding stakeholder needs, prioritizing features, and ensuring the backlog is transparent and visible. However, the actual implementation of these backlog items is the responsibility of the Developers. They have the technical knowledge and expertise to assess which items are feasible, independent, and deliverable within the constraints of a sprint.

Why This Misconception Is Problematic

When the Product Owner oversteps and dictates the sprint tasks, it creates several issues:

Undermines Developer Accountability: Developers are accountable for the work completed during the sprint. If they are not involved in selecting the tasks, their ability to commit to and deliver on these tasks is compromised.
Ignores Technical Expertise: Developers are the ones with the hands-on experience and technical skills necessary to gauge the complexity and interdependencies of the tasks. By excluding them from the decision-making process, teams risk selecting inappropriate tasks that may not be deliverable within the sprint timeframe.
Erodes Trust: Effective Scrum relies on mutual trust. When Product Owners dictate sprint tasks, it signals a lack of trust in the Developers’ ability to manage their work, which can lead to demotivation and disengagement.

The Product Owner’s Role in Ordering the Backlog

A proficient Product Owner will order the Product Backlog to maximize value, but also actively seek input from the Developers. This collaborative approach ensures that the backlog not only aligns with business priorities but also accommodates technical realities. Enabling work, technical debt, and other critical tasks should be prioritized with input from those who understand the technical landscape best—the Developers.

The Developers’ Autonomy in Sprint Planning

Developers must have the autonomy to pull work “out of order” when it makes technical sense. This flexibility allows the team to adapt to emerging dependencies, unforeseen challenges, and optimization opportunities. When such deviations occur, they should prompt discussions that ensure the entire team understands the rationale behind the decision. These discussions should focus on technical and strategic reasons, avoiding subjective motivations like personal preferences.

Fostering Trust and Professionalism

Trust is the cornerstone of successful Scrum practice. The Product Owner must trust the Developers to manage the Sprint Backlog effectively, just as the Developers trust the Product Owner to prioritize the Product Backlog judiciously. This mutual trust encourages professionalism, accountability, and open communication.

When Developers are trusted to manage their work, they are more likely to take ownership of their tasks, leading to higher engagement and productivity. Conversely, when Product Owners trust Developers with this responsibility, it fosters a collaborative environment where both parties feel valued and empowered.

Addressing Trust Issues

If a Product Owner finds themselves deciding what work Developers should deliver in a sprint, it highlights a deeper trust issue that needs addressing. Building this trust involves:

Open Communication: Regularly discuss priorities, challenges, and feedback openly within the team.
Collaborative Planning: Involve Developers in the sprint planning process, allowing them to provide input and make decisions.
Reflective Practices: Use retrospectives to identify and address trust issues, facilitating an open dialogue about how to improve team dynamics.

Conclusion

Understanding and respecting the distinct roles within Scrum is essential for maximizing efficiency and delivering high-quality products. The Product Owner should focus on prioritizing and articulating value, while the Developers should have the autonomy to manage the Sprint Backlog. By fostering an environment of trust and open communication, teams can navigate the complexities of development more effectively and achieve their goals more consistently.

Empowering Developers to own the Sprint Backlog not only leverages their technical expertise but also builds a more cohesive, motivated, and high-performing team. Trust your team, respect their insights, and watch as they deliver exceptional results sprint after sprint.

Priming: A Powerful Tool for Business Analysts

Written by Olam Osah on June 26, 2024. Posted in Articles.

“Big doors swing on little hinges.” – W. Clement Stone

Imagine walking into a store and hearing your favorite song playing in the background. Instinctively, you feel more at ease, more inclined to browse, and perhaps even to buy something. This subtle influence on your behavior is no accident—it is an example of priming at work. Now, picture leveraging this same psychological phenomenon to enhance the effectiveness of business analysis. Welcome to the world of priming, where a well-placed word or image can shape perceptions, drive engagement, and ultimately lead to more successful projects.

Historical Context of Priming

Priming, a concept rooted in psychology, began to gain traction in the 1970s. Researchers like David Meyer and Roger Schvaneveldt conducted seminal experiments demonstrating how exposure to certain stimuli could influence subsequent responses. For instance, people could respond faster to related words (like “doctor” and “nurse”) than to unrelated ones (like “doctor” and “bread”). This discovery highlighted the subconscious ways in which our minds process information, laying the groundwork for priming’s application across various fields, including business analysis. The foundational studies revealed that our brains are wired to create associative networks, meaning that exposure to a particular concept can automatically activate related concepts. This insight has been pivotal in understanding how to strategically use priming in business contexts to shape decision-making, improve stakeholder engagement, and enhance communication strategies.

Real-Life Examples of Priming

Priming has been effectively used in many real-world scenarios. For instance, in retail, stores often play specific types of music to influence customer behavior. A study by North, Hargreaves, and McKendrick (1999) found that playing French music in a wine store increased the sales of French wines, while playing German music boosted the sales of German wines. This subtle priming technique tapped into customers’ associations between the music and the product.

In another example, Priming is a powerful tool in political campaigns, frequently used to shape public opinion by consistently emphasizing particular themes or issues. Barack Obama’s “Yes We Can” and “Change We Can Believe In” slogans serve as prime examples of this strategy in action. These slogans were not just catchy phrases; they were meticulously crafted to prime voters to embrace a sense of collective empowerment and the possibility of positive change.

During Obama’s campaign, the repetitive use of these slogans created a cognitive framework that associated his candidacy with optimism, hope, and unity. Every time voters heard “Yes We Can,” they were subtly reminded of the potential for change and progress, fostering a sense of personal involvement and collective action. This emotional resonance was further reinforced through speeches, advertisements, and campaign events that consistently highlighted these themes.

The effectiveness of this priming was evident in the overwhelming support Obama received, particularly from younger voters and minority groups who felt directly addressed and included in his vision. The campaign’s ability to prime these voters to associate Obama’s candidacy with positive change and empowerment played a crucial role in his electoral success.

Personal Anecdote: Priming in Action

In my experience as a business analyst, I have found priming to be an invaluable tool in guiding stakeholders towards beneficial decisions. One notable instance was during a project aimed at selecting a software solution for case and document management.

Having previously worked with a highly effective software that streamlined operations and significantly reduced processing times, I was confident it would be the ideal choice for our current project. However, I knew that simply presenting this software as the best option might not be enough to gain stakeholder buy-in.

To prime the stakeholders, I began by sharing a series of success stories and case studies from other organizations that had successfully implemented this software. In pre-meeting materials, I included testimonials from satisfied users and highlighted measurable improvements in efficiency and accuracy. During our discussions, I subtly referenced these examples, framing our needs in a way that aligned with the strengths of the software.

As a result, when it came time to evaluate potential solutions, the stakeholders were already positively inclined towards the software I had in mind. The decision-making process was smoother, and the eventual adoption of the software led to significant improvements in our case and document management processes.

Applications of Priming in Business Analysis

Having seen how priming can effectively influence stakeholders in a real-world project, we can now explore how this technique can be systematically applied in the realm of business analysis.

The application of priming in business analysis provides a strategic advantage in enhancing stakeholder engagement, improving requirements elicitation, facilitating change management, and ensuring clear communication. By understanding how subtle cues can influence perceptions and decisions, business analysts can effectively guide project outcomes. However, the true power of priming lies in its implementation. To harness this potential, it is essential to employ specific techniques that ensure priming is both subtle and impactful, driving the desired results while maintaining ethical standards.

Implementing Priming Techniques

Now that we understand the applications of priming in business analysis, let us delve into practical strategies for effectively implementing these priming techniques in your projects. To effectively implement priming techniques, business analysts should consider the following steps:

Conclusion

Priming is a subtle yet powerful tool that business analysts can use to enhance their effectiveness in various aspects of their role. By understanding and strategically applying priming techniques, analysts can improve stakeholder engagement, facilitate better requirements elicitation, support change management, and enhance communication. As with any tool, the key to successful priming lies in its thoughtful and ethical application, ensuring that it serves the best interests of the project and its stakeholders. Drawing on historical insights, real-world examples, and personal experiences, business analysts can harness the power of priming to drive project success and foster positive outcomes, ultimately shaping the landscape of business analysis for the better.

Mapping Success Together: Tips for Inclusive Process Maps

Written by Adam Pearson on May 29, 2024. Posted in Articles.

There are numerous things that we can do to make process maps more inclusive; however, while they tend to go against established practices, they offer a range of benefits to making maps more inclusive for all.

A process map should be standardized within a business to map out the steps to achieve a business goal and show sequential steps, tasks, and gateways. There are a few established standards (UML, BPMN, etc.). My aim is not to advocate methods but to encourage inclusive standardization. Consistency is key, as it enables comparison and evaluation and can also assist colleagues with neurodiversities.

Typically, there are two sight-loss personas: low vision and no vision. Low vision is when a colleague has a combination of: fields—the amount of sight you have (half-close your eyes to see top and bottom field loss). The other is acuity, which is how sharp it can be seen (almost fully closing your eyes until the words go fuzzy can demonstrate acuity loss). The huge amount of variation between fields and acuity loss means that it is very hard to get a one-size-fits-all solution to sight loss.

The second persona has no vision. This is typically what you think of when you think of the word “blind.” No vision means no useful vision—you may be able to see something, but you cannot understand it without third-party intervention. Only a small percentage of vision-impaired people have no vision, but it is crucial to ensure inclusivity for them.

Process maps are inherently visual, so the following tips are mostly based on low vision. Low-vision users, with some tweaks, can read process maps if care is taken by the business analysts to make them as inclusive as possible.

Firstly, some whole-map tips. Use a clear font, classified as “sans serif.” These are simple, non-fancy stroke fonts that are easy to read, e.g., Arial and Calibri. Bad examples are brush script, harlow solid, and monotype cursive. Another consideration is the font size. Typically, it is best to produce it in large print, size 14, or giant print, size 18. This is not just helpful for those with low vision but will also reduce eye strain for fully sighted users. San-serif fonts are also dyslexia-friendly.

Secondly, make the connectors, or the lines between process steps, consistent in both thickness and color. The thicker the better, as there is more chance of seeing them, but they must also be in proportion to the other objects, or else it will look so odd that few people will engage seriously with the map. This is the balance between usability and accessibility.

Thirdly, low-vision users will zoom in a lot more than they are used to, sometimes only having a few letters on screen. With this in mind, there are two things that must be considered: Navigation: ID codes. By coding every step, data object, or note, you allow a low-vision user to navigate quicker using metadata instead of engaging with the full object. Each object class should be different; typically, I use process steps as numbers, notes as N1, N2, etc., and data objects as D1, D2, etc. Depending on which software you use to map your process, this can also assist any user in searching quickly and efficiently.

Screen real estate is also an important consideration. The more you zoom in, the less you can see the bigger picture. So, if objects are spaced far apart, it’s harder to understand the map. I recommend placing objects close together. Where you have multiple connectors coming out of an object, line them up so they overlap, looking like one connector, and have them branch off with the connector text as close to the break as possible, allowing someone who is zoomed in to be able to follow with ease.

Fourthly, color is important. There are several vision-impaired color schemes, such as yellow on black, white on black, etc. These are all highly subjective but share one common feature: they are high-contrast colors. My advice then is not to use similar colors, such as black and grey, white and silver, or white and yellow, as these types of pairings are very hard to see and can be easily missed or unreadable. Neon colors are highly effective, as most accessible technology offers color inversion, and when you invert a neon color, it stays the exact same shade, meaning there can be no misunderstanding in color coding like RAG systems. I advise only using one color scheme, or at most, in the case of impact assessing a process, a RAG for change size and blue for new—all in neon colors.

Finally, for all users, but specifically No Vision users, think about object semantics. By this, I specifically mean connector lines. Accepted practice means that we have no arrow heads on lines, and a double arrow head is assumed. This is presumably to make it look nice. A screen reader, though, has no context for this as there is no semantic instruction to relay to the user. Therefore, adding doule arrow heads will allow the semantic meaning to go through the connector. This is because a screen reader will consider the connector itself, not the thing it is connected to, which is what a person with sight will do. All a screen reader will visualize is a line, and a sighted user will see the line and the objects connected.

To summarize, process maps are visual. We can make them inclusive of low- and no-vision users by adapting our frameworks and standards. Specifically, by looking at font type and size, object layout and identification, color schemes, and the semantic meanings of diagram objects, we can minimize the risk of low- or no-vision users not understanding, thus making the business more inclusive and effective.

These tips are by no means exhaustive nor gospel, so please feel free to use them as a starter for ten, and hopefully they will help you kickstart your own inclusive process map designs!

Business Analysis: How and Why Do I Need To Evolve?

Written by Esther Folorunso on May 15, 2024. Posted in Articles.

Without a doubt, artificial intelligence (AI) is here to stay and is not going anywhere. Still, it would and has even started disrupting the status quo of many industries and organizations. Well, this is an undisputable, crucial innovation. Still, I would gladly refute Elon Musk’s’ claim that “We will have for the first time something smarter than the smartest human. It’s hard to say exactly what that moment is, but there will come a point where no job is needed” (Marr,2023).

The human factor must be considered in every career path or industry; however, professionals in every space and sphere must evolve with the dynamic and changing environment.

Why do we need to evolve?

Regarding my specialization as a Business Analyst, how and why do I need to evolve?

Recently, there has been a surge in the search for business analysts. This is not because this is a new field; instead, it has existed since the Middle of the Old Stone Age, when the ancestors were able to effectively adapt to the changing natural environment, identify their needs, problems, and opportunities, and develop solutions to make their abode livable and habitable.

What is Business Analysis?

According to the BABOK Guide V3, Business analysis enables change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change and design and describe solutions that deliver value.

The business analysis field has undergone several nomenclature changes and could be referred to by different names in different industries. Some famous names include Business systems analysis, business process analysis, functional analysis, product ownership, systems architecture, project management, usability analysis, user experience consulting, operations assessment, and technical writing.

Business Analysis Requirements

The BABOK Guide v3 views requirements as a usable representation of a need and a design as the usable requirement of a solution. Still, both concepts can be used interchangeably and primarily depend on the context of being used or adopted. Requirements need to be identified, collected, modeled, analyzed, validated, verified, traced, prioritized, managed, and maintained in the lifecycle of a project (Pre and post-project stages). Still, they are all related to a business problem that requires a solution. It could be in the form of an organizational objective that must be met, a business process that needs to be optimized, and an existing solution that needs to be improved or even retired. The BABOK guide v3 defines a Context as the circumstances that influence or are influenced and provide an understanding of a required change. This explains that requirements are broad and depend on the context, such as industry, regulation, project, weather, attitudes, behaviors, etc.

Unpacking BA requirements for Artificial Intelligence

Business analysts should not view themselves as AI experts but understand that they exist to drive change while still understanding the capabilities that AI provides and its complexities. Business analysts must see themselves as a bridge between business needs and AI capabilities.

Understanding the complexities of AI algorithms may and may not be a hard nut to crack; however, with a fundamental understanding of Natural language processing/ machine learning and knowing that most AI tools have been embedded with the critical technology to understand human language, as well as the ability to sieve through large data sets and establish a pattern or relationships, could serve as helpful information. Business Analysis could also establish broader knowledge of AI capabilities.

Also, the core of business analysis is need identification and solution generation. Both are valuable, but the most critical is correctly and efficiently identifying existing needs or problems, thus providing room for developing requirements and generating solutions.

This brings us to the question: can AI help in need identification or problem assessment? Realistically, with established data and available documentation, AI could help identify a need, but Hey, that need would be missing users’ humanity. Whatever solution is generated should provide or enhance satisfaction. However, can AI understand the complexity of the human emotion? With AI, we could develop the goals, desired outcomes, and key performance indicators (KPIs) and define roles and responsibilities, but how can usability be assessed?

With AI in business analysis requirements comes data quality, security, and privacy requirements. Every requirement generated for BA activities must answer these 3 data prongs. How reliable is the requirement gathered? If a requirement is trustworthy, it could speak to its quality. Was the requirement confirmed, verified by necessary stakeholders, and validated to align with identified needs?

To achieve these three tasks, the requirements must be specified and modeled to fit the organization’s environment with due consideration of the stakeholders involved. The modeling can be in the form of matrices or even diagrams, for which AI could be beneficial. Still, the prompts must be correct, which reflects the data quality and reliability. Using AI to generate, specify, or even model requirements (inexhaustive) would lead to data security and privacy prongs.

Privacy and security are critical issues in the professional world, not just business analysis. Before every BA task, how AI should be adopted and what data should be provided as AI prompts need to be addressed. There is a need to protect user privacy and define adequate security measures, as IT systems are susceptible to attacks. Privately owned AI tools can still be attacked; strict security and privacy rules must be strictly followed.

This is also very important as some requirements can serve as Unique selling points for a specific business or even a trade secret. In this situation, the use of AI might be optional.

Conclusion

Knowing that the Business analysis role will continue to evolve as a context evolves or dictates or even as a business dictates while putting Artificial intelligence as an addition in a context, it is recommended that the requirements generated in previous contexts be adequately managed and maintained for reuse. When done correctly, this would enhance knowledge sharing as AI could help create a central repository for past project requirements, thus making it easier for business analysts to learn from past experiences and build on existing knowledge, which could lead to overall project success.

Beyond The Happy Path: One Size Does Not Fit All

Written by Adrian Reed on May 15, 2024. Posted in Articles.

Up until a few years ago, I used to spend a lot of time working ‘on the road’. I’d spend time traveling between different client-sites, and this would inevitably mean spending far too much time in airports. Business travel is one of those things that sounds really glamorous until you do it, but believe me it soon gets really boring.

When you are a regular traveler, you tend to become very familiar with certain airports and you know exactly how to transition through them quickly. If you’re ever at an airport, you can usually spot regular travelers as they tend to know exactly where they are going, and tend to move at pace. This is completely different to the family who are checking in with three kids, who are having to refer to the signs, and might have even initially arrived at the wrong terminal. Quite understandably, they often need a little bit more help.

I used to joke that it would be good to have an entrance especially for regular travelers, as their needs are so different (I certainly wouldn’t be buying anything from the duty free store, not even one of those giant airport Toblerones that seem ubiquitous in Europe, but a family may well do). This wouldn’t be practical in airports, but it does highlight a point that has direct relevance for business and business analysis: sometimes you need two (metaphorical) entrances…

Understanding Different Usage Patterns

When defining a process, journey or set of features for an IT system, it’s common to think about one path or scenario through which users will navigate. This main success scenario or ‘happy path’ is then often supplemented by exceptions and alternative paths which are essentially ‘branches’ from the main scenario.

Yet it is worth considering that different types of stakeholders might have different needs as they navigate through. There might even be benefit in having two entry points. Building on the airport analogy, an experienced traveler probably doesn’t need to be told about the security rules (unless they have changed recently). A new or less frequent traveler may well need to be informed in detail.

This translates to wider contexts too. An experienced user of an IT system probably won’t want lots of dialogue boxes popping up with hints and tips. A new user might need virtual hand-holding as they learn how the application works. Someone who calls a call center once might need to hear that three minute Interactive Voice Response (IVR) message explaining all about the services they can access via phone, and letting them know which number to press. Someone who calls every day as part of their job probably doesn’t need to listen to the whole three minute spiel every time they call… Understanding these usage patterns is key.

One Size Rarely Fits All

There is often a desire to standardize processes, journeys and customer experiences. There is benefit in doing this, but the benefit really surfaces when the different users and stakeholders are understood. Understanding whether users will be casual/occasional or regular is important, as is understanding what they are ultimately trying to achieve.

This relies on elicitation and customer research. This is an area where business analysts can add value by advocating for the customer’s perspective. Too often definition and design decisions are made by people in comfortable conference rooms who are detached from what the experience will actually be like. Sometimes those decisions are made by people who haven’t spoken to a real customer in a decade (or ever!).

In these situations we can ask important but difficult questions such as “what evidence do we have that customers want that?”, “which types of customers does that appeal to most?” or “how do we know this will be a priority for our customers?”. Using a technique such as personas, when coupled with proper insight and research, can make a real difference here.

As in so many cases, asking these questions can sometimes be uncomfortable. But if we don’t ask them, who will?