Skip to main content

Tag: Planning

BATimes_July25_2024

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

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:

  1. 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.
  2. 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.
  3. 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.

 

Advertisement

 

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:

  1. Open Communication: Regularly discuss priorities, challenges, and feedback openly within the team.
  2. Collaborative Planning: Involve Developers in the sprint planning process, allowing them to provide input and make decisions.
  3. 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.

BATimes_Jul03_2024

Mastering Business Analysis: 7 Strategies for Effective Internal Best Practices Sharing in Teams

Effective transmission of internal best practices within a business analysis team is crucial for fostering consistency, efficiency, and continuous improvement. As business analysts navigate complex projects and evolving client needs, harnessing collective knowledge and refining methodologies can significantly enhance outcomes. Here are some essential tips and approaches to facilitate this process:

  1. Document and Standardize Processes:

Begin by documenting existing best practices and standardizing processes. This creates a foundation for consistency and clarity within the team. Utilize tools like process maps, checklists, and templates to outline workflows, methodologies, and key deliverables. Ensure these documents are easily accessible and regularly updated as practices evolve.

 

  1. Establish a Knowledge Sharing Culture:

Promote a culture of knowledge sharing where team members are encouraged to contribute insights and lessons learned. Facilitate regular team meetings, workshops, or brown bag sessions focused on sharing best practices, case studies, and success stories. Encourage open dialogue and feedback to refine practices collaboratively.

 

  1. Mentorship and Peer Learning:

Implement a mentorship program where experienced analysts mentor junior colleagues. This not only facilitates the transfer of best practices but also promotes professional development and skill enhancement. Encourage peer learning through shadowing opportunities, joint project assignments, and cross-functional collaborations.

 

  1. Leverage Technology and Tools:

Utilize technology platforms and collaboration tools to facilitate knowledge sharing and practice transmission. Implement a centralized knowledge repository where team members can access resources, templates, case studies, and recorded training sessions. Leverage project management software for task management, progress tracking, and documenting lessons learned.

 

Advertisement

 

  1. Conduct Internal Trainings and Workshops:

Organize regular internal trainings and workshops focused on specific aspects of business analysis. Topics can range from requirement elicitation techniques to data analysis methodologies and stakeholder management strategies. Invite external experts or senior leaders to share industry insights and best practices.

 

  1. Encourage Continuous Learning:

Support ongoing professional development by encouraging team members to pursue certifications such as CBAP or PMI-PBA. Provide access to relevant courses, webinars, conferences, and literature. Foster a learning culture where individuals are empowered to stay updated with industry trends and emerging best practices.

 

  1. Measure and Improve Effectiveness:

Establish metrics to measure the effectiveness of internal best practices in transmission. Monitor key performance indicators such as project success rates, client satisfaction scores, and team productivity. Solicit feedback from team members through surveys or focus groups to identify areas for improvement.

 

In conclusion, transmitting internal best practices within a business analysis team requires a strategic approach focused on documentation, culture building, mentorship, technology integration, continuous learning, and performance measurement. By fostering a collaborative environment where knowledge sharing is valued and supported, organizations can enhance their capabilities, deliver superior outcomes, and drive innovation in business analysis practices.

BATimes_Jun8_2024

Key Documentation Prepared by Business Analysts

Documentation is the core part of the business analysis process that provides clarity, standards, and process details that help organizations in decision-making. The documentation provides information about the guidelines, requirements specifications, roadmaps, communications, blueprints, and solutions that are crucial for the execution of the project.

Business analysts create various documents to translate complex requirements into accessible language that can be understood both by the technical and non-technical staff of the team. Business analysts bridge the gap between the business stakeholders and the technical team by creating various documentation that provides clear, concise information on the problem statement, business objectives, key requirements, restrictions, exclusions, and solutions that help in the alignment of the team.

A well-crafted document by the business analyst helps the organization secure the budget required for the execution of the project and forecast any risks during the implementation of the project. Documentation also helps to align the project with the overall organization goal and describes the value added to the organization goal by the execution of the project.

 

Key Documentation Prepared by The Business Analyst

  1. Business Requirements Document (BRD):

The business requirements document is one of the most common documents that is prepared by a business analyst. BRD captures the big picture of the project and stakeholders’ business needs. It provides detailed information on the project goals, objectives, and approved solutions, along with the key deliverables that define the scope and associated benefits of the project’s execution.

Although the fields in the BRD change from organization to organization, here are the key fields in the BRD document:

  • Project details

The project details section includes information such as project name, project number (if applicable), organization department details, business sponsor details, key stakeholder information, project manager, architects, and details of the technical team members working on the project.

  • Project Overview

The project overview provides high-level project objectives and their benefits. This is the section one would read to get the complete summary of the project.

  • Project scope and out-of-scope items

The project scope lists the deliverables of the project; this helps both business stakeholders and the technical team be on the same page and provides clarity on requirements.

Project out-of-scope lists all the items that are identified as outside of the project scope. Identifying the out-of-scope during the initiation of the project helps to avoid any scope creep during the execution of the project.

  • Assumptions

The assumptions section provides a complete list of assumptions relative to the scope of work. These assumptions are agreed upon and approved by the business stakeholders.

  • Current and future state business processes

The current state of the of the business process depicts a snapshot of the current state of the organization, and the future state highlights the deliverables of the project.

This section helps to have a side-by-side comparison of the enhanced functionality that will be achieved by the project.

  • Business requirement

The business requirement is the main section of the BRD. This section lists all the action items that are required to achieve the project scope.

Along with the action items, it is important to assign priority to each item, as it helps the technical team identify which task they need to pick first.

For projects where the implementation of the business requirements is divided into multiple releases, it is important to include release details in the business requirements section.

  • Business rules

The business rules section consists of all the project-relevant business rules that were agreed upon and approved by the stakeholders. Business rules usually trace back to business requirements.

  • Project risks

The project risks section includes all the risks identified and mitigation measures for the risks. Identifying the risks ahead helps the team focus on their tasks and reduces uncertainty during the execution of the project. Identifying risks earlier also helps to make better business decisions.

  • Cost-benefit analysis

Cost-benefit analysis is the last section of the BRD. In this section, you describe how the project objectives will make a profit for the organization and estimate the ROI that can be achieved with the execution of the project.

 

Advertisement

 

  1. Functional Requirements Document (FRD):

The Functional Requirements document provides information about the business problem and approved solutions for the problem. FRD is the contract between the business and the technical team to deliver the accepted solution. It provides information about key functionality that a solution system needs to have and the performance of the system. FRD captures all the nitty-gritty information about the solution product.

The FRD document is different from the BRD , as FRD focuses more on the nitty-gritty details of the solution and BRD focuses on the broader view of the overall project.

The style and fields of the FRD document change from project to project. Here are the key fields of the FRD document:

  • Project details

The Project Details section includes detailed information about the project, such as project name, project unique number, organization department details, business sponsor details, key stakeholder information, project manager, architects, and details of the technical team members working on the project.

  • Project Description

An overview of the project, its benefits, and the approved solution. This is the section one would read to get a complete overview of the project.

  • Project Background

The project background describes the problem statement of the project and the purpose of the project.

  • Project scope and out-of-scope items

The project scope lists all the deliverables of the project, including the technical details of the solution system. This section helps both business stakeholders and the technical team be on the same page and provides clarity on requirements.

Project out-of-scope lists all the items that are identified as outside of the project scope. Identifying the out-of-scope during the initiation of the project helps to avoid any scope creep during the execution of the project.

  • Assumptions

The assumptions section provides a complete list of assumptions relative to the scope of work. These assumptions are agreed upon and approved by the business stakeholders.

  • Functional requirements

The functional requirements section describes what the system must do. Functional requirements must be drafted in a way that provides complete information about the business needs and specifications needed in the solution system.

  • Operational requirements

The operation requirements section describes how the system must operate, i.e., how fast the system should respond, how many responses the system needs to provide in the given time, etc.

  • Requirement Traceability Matrix

The requirement traceability matrix is described in detail in the section below.

The requirement traceability matrix is used to track the implementation of the functional requirements. The RTM is updated throughout the project to show the progress made in the implementation of the functional requirements.

  • Glossary

List all the business terms and their definitions.

 

  1. Non-Functional Requirements Document

The non-functional requirements document defines how the system must behave. This section is crucial for the execution of the project; it describes the capabilities of the system operation and its constraints. Non-functional requirements provide information about system users, scalability, operation, hardware and software, performance, retention and capacity, accessibility, and security.

The solution system can still operate by just executing the functional requirements, but it might not meet all the business expectations in terms of security, performance, scalability, etc.

 

Below are the fields that are going to be part of the Non-Functional Requirements document:

  • Security

Security is the most important section of the non-functional requirements document. This section captures all the security guidance that needs to be incorporated by the project execution team during the implementation of the project. It captures security architecture guidance, authentication, data security, risk management, and technology development guidance.

  • Users

This section provides information about the business expectations for the number of users that will use the system. And a number of concurrent users that the system can support without letting the system performance degrade.

  • Scalability

This section captures business expectations for the data volume that the system must support. It also captures the volume that the system can support during peak and non-peak times.

  • Operational

The operational section is different from organization to organization; this is the section that captures the Tier 1, Tier 2, Tier 3… (Severity 1, Severity 2, Severity 3…) incidents that arise and the action plan to resolve the incidents. Based on the severity of the incident, a recovery strategy is defined to get the system back up and running.

  • Hardware and software

This section includes information about any new hardware components required for the execution of the project and the specifications of the hardware components.

It also captures any new software installation or software configuration required for the completion of the project.

  • Performance

The performance section answers questions such as how fast the system needs to perform. What should be the response time of the system?

  • Retention and capacity

The retention and capacity section captures data types that need to be stored in the database and the data retention time frame required for the data. It also talks about the capacity of the database and the various logs that will be available.

  • Accessibility

This section captures information about who can access the system and the minimum requirements for accessing it.

 

 

  1. Requirement Traceability Matrix

The Requirement Traceability Matrix is the document used during the implementation of the project to trace the requirements to its test cases and further to any defects. The main purpose of this document is to prove that all the requirements have been successfully executed and tested by the project execution team.

The requirement The traceability matrix generally consists of the following fields:

  • Requirement Number

The requirement number is the business requirement or the functional requirement number that is captured in either the BRD or FRD document based on organization standards. All the requirements for the project are listed in this column.

  • Requirement description

A brief description of the requirement.

  • Test case number

The test case number is the unique number used to identify the test case for a particular requirement.

  • Testcase description

A brief description of the test case and its scenarios.

  • Test execution result

This section captures if the test case was a ‘Pass’ or Fail’ during the execution of the test case.

  • Defect number

If the test case execution fails, then a corresponding defect is created, and this section captures the defect’s unique number.

  • Defect Status

This section is used to capture defect status such as ‘Open’ or ‘Complete’. This helps to know if the defect was successfully fixed and tested.

 

Conclusion

Throughout this paper, we have discussed various documents prepared by a business analyst that play a crucial role in the project’s success, driving communication and streamlining the process. From the initiation of the project to the implementation and final deployment of the product, these key documents guide the team through the project lifecycle and ensure the team is aligned with business objectives at every step of the project.

BATimes_Feb14_2024

Prints, Processes, and Pitfalls: More Than Just Process Design!

I was recently planning the logistics of an upcoming client workshop. I needed 12 copies of a document printed and spiral bound, and I visited the website of a printing company that we’ve used many times before for such tasks. The website had changed, and unfortunately I couldn’t complete the order.  For some reason the website was saying it couldn’t deliver to my address.

 

I’m pretty sure I know why this is.  I live in Portsmouth, on the South Coast of the UK, and to the uninitiated, some Portsmouth postal codes look similar to postal codes used on the Isle of Wight. I suspect some courier firms don’t deliver to the Isle of Wight (or charge extra as it’s an island with no roads connecting it to the mainland). This leads to some online sites (incorrectly) lumping some or all of the post codes together and tag them as an ‘exception’.  This is really, really, bad design, but it definitely happens.

I was trying to place the order on a weekend, so I waited until Monday and went to contact the company by phone. I tried to phone shortly after 9, and then again at 9.30, and then again at 9.45. No reply.  So, even though I’d used this company many times in the past, I just moved on to another supplier. And in fact, I’ll probably use this new supplier in the future, too. So the original printing supplier has lost a customer and it doesn’t even know that. Plus, it missed the opportunity to get feedback about the defect on their website… I wonder how many other cities/postal codes are affected? How many other sales are being routinely lost?

 

Considering The Customer’s Pivotal Moments In Process Design

As a business analyst, this experience made me think about process and operational design. While the example above was an example of bad design, it is impossible to design an IT system, interface or process that truly caters for every situation, nor (in most situations) would you usually want to. Sure, some call centers might have a process which defines the detailed steps to take if the President of the United States calls from a satellite phone while onboard Air Force One and asks for a message to be passed urgently to the CEO… but not many!

The point here is that there will be certain types of situations that are:

 

  • Predictable, but very unlikely and/or uniquely complicated
  • Difficult (or impossible) to predict, with unknown levels of likelihood or complexity
  • Unintended, where with the best will in the world (and lots of testing) still something unexpected has happened which has led to an unintended consequence

 

The first set (predictable) are deliberately not fully catered for by a process as they are either so unlikely that spending time specifying them is overkill, or they are so uniquely complicated that anything beyond broad guidelines can’t be issued. I’d imagine that large companies have a “respond to media request” process which ensures that any inquiry from a TV station or newspaper gets to the right person. The broad process will be structured, and the response will likely be logged in a consistent way. However, how the response is formulated is probably somewhat variable, and more likely subject to guidelines and principles than a strict process. Responding to a request for a photo of the CEO to accompany a “top 10 CEOs” article is likely to be somewhat different to responding to notification that a documentary will be airing showing evidence of corruption within the company!

 

The second set of (difficult or impossible to predict) conditions can’t be catered for as they are unknown, or the effort of trying to predict them is so great that it is prohibitive.  The final set (unintended consequences) are, by their nature, unpredicted! The key here is to find them when they occur and rectify not just the individual case, but the root causes. Taking my printing example, had I got through to the first printing company, I suspect they’d have quoted me via phone and manually processed the order. Great—except the website is still faulty and swathes of other customers might be affected. Understanding what needs to change to prevent the issue happening again is key.

 

So, what aspects can be considered when designing customer journeys, IT systems and/or processes to cater for these types of situations?

 

Advertisement

 

Flexibility, Feedback and Responsiveness are Key Factors

Assuming an organization wants to handle these types of cases, it’s key to design processes with feedback mechanisms built in. Feedback should of course include opportunities for customer or user feedback, but it can also include feedback generated by the process itself.

Take the printing company example I mentioned earlier. As a nationwide printing firm, they are almost certainly finding that there’s been a minor drop in Sales (Portsmouth is a relatively big city, but probably not big enough that the drop in printing sales would ring any warning bells) and the distribution of where they are sending parcels has changed. A curious analyst diving into the data might say “hmmm, it’s odd, there are entire cities where we are no longer sending parcels… maybe we should look into that”.  Making sure diagnostic data is captured and examined is important, and this is so much more than just performance data.

It’s also important to ensure there’s a viable support option and, yes, this does usually mean ensuring someone can speak to (or communicate somehow with) a human being when they need to! That support person or team needs to have sufficient autonomy and be empowered to raise issues for investigation. A team that just “raises tickets” and passes them on to others is unlikely to cut it.

 

Finally, it’s important to note that processes will need to change and this should be expected. Building in responsiveness to the environment is important. Expectations will change, the way people communicate will change and so forth. By designing processes with this in mind, and ensuring they are owned, reviewed and adapted when needed, is a small but important step towards agility.  As BAs, we can often nudge towards this way of thinking, and every step in the right direction is a good thing!

 

 

BATimes_Jan24_2024

An End and a Beginning: A Practical Application of Business Analysis Techniques

Business analysis is not just an IT-related profession; it is a profession that has expression in every facet of life, and hence one of the reasons why you should take pride in this profession if you are a business analyst or why you should aspire to be one.

The tools and techniques are transferable skills that have applications or expressions in other aspects of life.

I briefly discuss two as the curtains close in 2023.

  1. Lessons learnt
  2. MoSCoW

Have you taken time to reflect on 2023 and list out the lessons learned? Making use of this powerful BA technique is one of the ways you can identify what went well in 2023, what didn’t go well, where you made mistakes, and what you can put in place to avoid those mistakes in 2024.

Note that this does not only apply to the current year or next year; rather, it is a set of business analysis techniques that can be applied to different seasons and phases of life.

  1. Lessons learnt

What went well?

A1: Why did it go well?

B: What didn’t go well?

B1: Why did it not go well?

C: What mistakes did I make?

D: What can I do to rectify or avoid the mistake in the future?

E: What are my achievements?

F: What lessons have I learned?

 

Advertisement

 

2. MoSCoW

Based on your analysis above and the lessons learned, you can draw up your plan for the future (the next phase).

A: What must be done?

B: What should be done?

C: What COULD be done

D: What won’t be done

This can also be seen as a positive thing to do in the new year and a negative thing to avoid.

While new year resolutions may be difficult for some, using the above BA skills should help you plan your coming year with hopefully less pressure.

Concluding Remarks

As a phase comes to an end and you look forward to a new beginning, take time to consider these business analysis techniques, take time to reflect on the lessons learned, and plan the MoSCow for the future.