Skip to main content

Tag: Agile

BATimes_Apr19_2023

Agile Requirements Management Part 3 – A Collaborative Data Model

Written by Steve Farrall on . Posted in Articles.

In this article I want to explore how to integrate data requirements with product features and user stories; the result is some very useful traceability to where a particular data entity or attribute is being used across a product.

A conceptual data model is an integral part of the analysis process, it allows the analyst to better understand the overall requirement and how the various elements are related to each other. This enables the correct features to be identified to support the requirement and may well identify some gaps in the requirement where data is not being setup ready for the next process to collect and consume.

The data model will then naturally provide the start point for the database design and will ensure that all the features and associated user stories are all be singing from the same hymn sheet. The sprint teams will benefit from a shared understanding of the data that they are being tasked to manage.

 

 

The Tool

 

Initially my thoughts were that a true data modelling tool with a built-in dictionary were needed, having used these kinds of tools in previous projects.

As the choice of tool was limited, we explored whether Confluence might provide a useful stand in solution; we were already using Confluence to manage the requirements and user stories, so this looked like a natural plug-in to our existing Confluence wiki.

 

 

 

Develop the Model

For convenience, a separate data modelling space was setup to hold all the diagrams and page content for the data model which could then be referenced across the Wiki pages to add understanding to the requirements.

The Confluence service we were using came with the Gliffy diagramming tool; this allowed us to create entity relationship diagrams (class models).  As the model was quite large, it was split into distinct data domains, this is easily managed by creating a view (diagram) for each domain.

 

 

 

Create Data Entities

In order to make the Confluence data model more like a true tool-based model, hyperlinks were included in the diagrams attached to drawing objects like an entity or domain; click on a high-level domain in the diagram view and the attached URL will then launch the associated domain view diagram, allowing a drill down to the detailed entity level.

 

 

Once down at the entity level, the next step is to setup each entity as a separate Confluence page; the last click at the entity level will arrive on a page that can be enriched with content for collaboration with the team.

Each data entity is loaded as a separate Confluence page; this approach also means that you can link to individual features and user stories using the page URL but also provides a ready-made folder to hold related content like data attributes.

 

Advertisement

 

Tip – Setup Data Domains

Setup a domain hierarchy in Confluence to file the entities appropriately, this will facilitate creating views of subsets of the model using the ancestor filter option in the reporting macro.

 

Trace Data Requirements

 

Now we have the model available in Confluence with each entity loaded as a separate page the data requirement can be integrated into the requirements wiki traced to the product features and included in user stories as a URL link to the relevant pages.

 

Tip – Identify Data Usage

The more comprehensive the application of this approach the greater value will be realised; if you go down to attribute pages then it will be possible to drill down to where data items are being processed.

 

 

Setup Data Attributes

 

Defining the data attributes is a useful activity to ensure that the system will include all the required data and manage it in a consistent manner.

Data attributes can be simple and self-explanatory items, the name alone can be enough to understand the purpose intended; however, it is often the case that the meaning can be very subtle and having an attribute page available to record an explanation is very useful.

Data attributes are setup as child pages to the parent data entity page to provide a natural filing plan but they can be referenced anywhere and shared in conversations with team members to clarify their purpose and ensure consistent data usage.

Tip – Attribute Names

Page names must be unique within a Confluence space, so it is a good idea to fully qualify the page name with the entity name as a prefix to avoid any duplication issues across different entities.

 

 

Integrate Data Requirements

 

This is where the data model becomes integrated and collaborative, a big advantage over separate modelling tools.

Whenever a user story is referencing a data requirement then the URL to the entity page can be plugged into the story as part of the narrative. For example, the narrative “Create a Customer record for the order received” can replace the plain text “customer” with a URL to the customer entity page instead. Once this approach is adopted the data usage can easily be discovered; starting from the entity page under the page information details all the incoming and outgoing links to the page will be shown, revealing where the data is used and with a single click the reader can jump straight to the story page.

Tip – Business Rules

Including attribute links in business rules will ensure the sprint teams are looking in the right place when implementing the user stories. For example, check the “order delivery date” has not be missed; otherwise, an alert must be triggered to follow-up on the delay with the customer.

 

Conclusion

Confluence may not appear to be the obvious tool to consider for managing data requirements; however, the fact that it can be integrated with the product features and user stories is quite powerful. The ability to see where individual data attributes are being used facilitates impact analysis and support; the business rules can be expressed precisely and facilitate the development of an integrated system.

It will require careful management to ensure changes can flow through the process and can easily be identified but this is true of all these kinds of tools.

Last but not least is a the record of feedback and comments added to the pages in Confluence, explaining why certain decisions were made and how data attributes introduced are being used by the system. This record will be invaluable for assurance and support queries to understand the how and why a piece of data is being used by the system.

 

BATimes_Mar30_2023

Agile Requirements Management: The Art of Collaboration

Written by Steve Farrall on . Posted in Articles.

In this article I want to expand on how to manage requirements, particularly focused on delivering user stories to development teams ready for sprint refinement sessions. The starting line is a set of requirements that have already been formulated and issued, for example as part of a tendering process for a new service or upgrade to an existing service.

The Tool

We adopted the Confluence wiki collaboration tool as it is well integrated with the preferred Jira sprint management tool from the same supplier, Atlassian. The objective was to build a knowledge base for the product that is sharable and retains useful insights posted by stakeholders and the project team; this will facilitate future enhancements but also be invaluable in answering the inevitable question – “Why did we do that?”

 

The start point is to load each requirement as a separate Confluence page; this approach means that you can link to individual requirements using the page URL but also provides a ready-made folder to hold related content. This has an initial overhead in loading the requirement pages but provides lots of advantages downstream, so its well worth the effort; we managed to load in excess of 800 requirements for one contract.

You may be thinking why not use a table embedded in Confluence page to hold all the requirements but this is hard to manage and you cannot easily address each requirement.

 

Tip – Setup Subject Areas

Setup a subject area hierarchy in Confluence and file requirements appropriately, this will facilitate creating views of subsets of requirements using the ancestor filter option in the reporting macro.

 

Trace Requirements

Add at least one trace for each requirement, one for each feature impacted by the change or new feature that will need to be developed.

In parallel, features can be added to the wiki, again as separate pages – one per feature; it does not matter that the feature page has little content at this stage, the aim is to have a place holder that is ready to receive content and will allow everything to start to become joined up.

If the feature is already in place, then you can just plug in the link in the trace page and you are ready to move forward.

Tip – Identify Impacts

Each impact will need a separate trace, however traces can be grouped together for delivery as a single story. Trace pages are filed as child pages to the parent requirement, so everything is kept together.

 

Advertisement

 

Validate the Solution

Validate the proposed feature changes with the Product Owner and SME’s, this is achieved using workshops and reviewing the trace page content and adding clarifications to pages during the sessions, so everything is up to date and immediately available to the team.

The sort of points to consider are – does the Product Owner agree with the introduction of a new feature or a change to an existing feature, are there better options to consider such as buying a third part add-in; these kinds of questions need to be answered before moving into a more detailed analysis of the requirements.

 

Tip – Agree Solution

Stories to be written are agreed before they are actually written to reduce the risk of wasted effort.

At this stage a story title may be added as a reminder to the author of what needs to be covered, this will then be replaced with the URL to the story page once it has been created.

 

The Collaboration Solution

I’m guessing by now people will be wondering how on earth will all those requirement, feature and trace pages be manageable once they have been loaded into Confluence.

This is where you can use a feature of Confluence known as the Decision macro, at first glance it does not appear to offer much – the ability to create logs of decisions to manage, so each decision is a separate page but you get a consolidated view that pulls them together – a bit like a spreadsheet.

The next step is to realise that requirements, traces and features are really just decisions – a decision to request a feature in a product, to deliver a product feature using an agile user story etc. The nice thing about decision pages is that they can be customised, we devised templates for each type of decision – requirement, trace, feature etc. So now we have logs of all our requirements, traces and features but each can be managed separately as a Confluence wiki page.

 

Tip – Setup Filters

Logs can become quite large, so the solution we adopted was to use the requirement subject areas to create filtered views that only included traces for a particular branch.

 

Create User Stories

Write the user story content to fulfil the requirements including the detailed process flows and business rules.

As stories may relate to multiple requirements they are filed in a separate branch and not under a specific requirement, they are still linked back to the requirement via the trace pages.

 

Tip – Story Content

Add as little or as much content to ensure that the requirement will be met including process flows and business rules.

This is more effective than trying to develop business rules once sprints have started.

User stories may be grouped together where a lot of stories need to be managed.

 

Validate User Stories

Check the proposed changes with SME’s, are the business rules correct, you may include mock-ups of user interfaces to facilitate the process and give context to the proposed changes.

 

Tip – Workshops

Workshops can be used to present user stories prior to development to mitigate the risk of the wrong solution being delivered.

 

Conclusion

Finally, we created a Jira ticket for each story and link it to the Confluence story page; Confluence is a better tool for content than Jira but they are both only one click away from each other. Click on the Jira link in the story page and you are taken to the Jira ticket and similarly you can navigate back from Jira to the Confluence story.

In fact, you can navigate right back to the requirement(s) behind each story, all the links will be setup and ready to use with no additional effort.

Don’t forget to update your feature pages with the story releases – cut and paste job mainly; otherwise, you will need to read through all the stories for a given feature, in chronological sequence, just to find out what it is currently meant to be doing in production!

BATimes_Mar15_2023

Your Next Process Model’s Degree of Abstraction

Written by Edmund Metera on . Posted in Articles.

Any process model is so much more than a flowchart. It is an abstraction of current or future real-world operations.

Process modeling is one of the core competencies of any capable business analyst. Both the International Institute of Business Analysis (IIBA) Business Analysis Standard[1], and the Project Management Institute (PMI) Guide to Business Analysis[2] call for certified business analysts to be capable of preparing and using process models.

Business analysts and process improvement analysts may prepare process models at key points of business process management, information technology, and regulatory compliance project methodologies. They may specify current or future functional, organizational, and information systems architectures, functional requirements, workflow designs, and even automated operations. What any process model needs to communicate will vary from one project to the next.  The highest quality process model examples provide clear, accurate process information of direct interest to their readers.

Informed business analysts know that one of the secrets to producing a high-quality process model is to establish a clear mission for each model. To be successful, you should mindfully establish the mission of your next process model within the business process management, information technology, or regulatory compliance project that the model will serve.  You will then tailor your elicitations of the model’s content and configuration to meet project needs. Part of your process model mission-setting elicitation agenda will include asking and answering this important question:

What is this model’s required degree of abstraction?[3]

There are three generally accepted degrees of abstraction to consider: conceptual, logical, and configuration.

 

A Conceptual Process Model  

A conceptual process model graphically presents the defining structure of what a process is.

Business analysts, project sponsors, project managers, domain subject matter experts, regulators, and other process stakeholders use conceptual process models, for the following purposes:

  • To make process governance and scoping decisions;
  • To gain agreement about and communicate the process’s defined scope and structure, unequivocally distinguishing that process from all others in their business;
  • To design enterprise architecture, to define technology solution architectures,
  • To be the sound foundation on which forthcoming detailed problem analysis or detailed process definition is scoped out or planned;
  • To support project management decisions (e.g. budgeting, scoping).
  • To further elicit and fit logical process details upon its sound contextual and structural foundation.

 

Some business analysts and systems analysts might interpret the term conceptual to mean “high level”. That would be an oversimplification and a mistake. To serve its purpose, a conceptual process model should unequivocally define the sound, stable structure of the process. Despite being the highest degree of abstraction, a high-quality conceptual process model is still precise.  It can clearly and graphically communicate all of these process-defining information:

  • The process’s name.
  • The process’s initiating event(s) that causes the process to be performed.
  • The process’s activities and their expected sequence of execution.
  • The process’s expected outcome(s).
  • The process’s customer(s).

 

Advertisement

 

A Logical Process Model

A logical process model elaborates contextually relevant details about how a process is required to operate, is designed to operate, or currently operates.

A high-quality logical process model could graphically, answer any of these types of how-elaborating questions:

  • The decomposition or summary of some of the process’s activities.
  • The rule-driven or decision-driven conditional work that may be performed.
  • The assigned responsibilities for performing the process’s activities.
  • The data or information required to be used and/or produced.
  • The causes of the process to be delayed or interrupted.
  • The processing errors that may occur while the process is executing, and how they will be resolved.
  • The process’s related performance or measurement data, and text-based operating procedures, documents, or other specifications.

There is a spectrum of uses for logical process models. Process owners and analysts use logical process models to determine what and where to measure an existing process’s performance or to design and communicate proposed process improvements. They also define requirements for, or the design of manual or automated procedures, or describe the design of workflows.

Competent business analysts and process analysts can anticipate, elicit and document a range of logical refinement types, using clear agendas and reusable modeling patterns[4]. They also know that no two logical process models need to communicate all of the same types of logical refinements. So they will consider the model’s mission within each project and tailor their modeling efforts to focus on eliciting and documenting the types of logical refinements that suit each model’s intended use within its project’s methodology.

 

A Process Configuration Model

A process configuration model communicates concrete implementation mechanisms such as software operations and user procedures or workflows.

A process configuration model is the lowest degree of abstraction. Business analysts and systems analysts typically prepare process configuration models in low-code and no-code software platforms. The platform consumes the process configuration model along with detailed process-related roles, security, forms, system interface, and data specifications to generate operating software, on top of an already well-rounded software product architecture. There is otherwise no or very little programmer intervention in translating the model into working software. When updates to requirements or defects emerge, the analyst revises the configuration model, and the platform regenerates and redeploys the software.

You must adopt and adhere exactly to a chosen low-code or no-code platform’s process modeling syntax. You can learn that by taking the training offered by the low-code or no-code platform’s vendor. Along with a process configuration model, you would specify, in detail:

  • System users, their assigned roles, and their responsibilities to perform the configured process flow.
  • The sequence of execution of configurable functional components, of an automated end-to-end workflow.
  • The configurable functional components involved in the process flow configuration. These are typically the user interfaces (e.g. forms, reports) system integrations (e.g. APIs), and the data attributes used in an automated process workflow.

Since process configuration models are precisely translated into operating software and business operations, any errors or omissions in the modeling become errors or omissions in the generated software and business operations.  It stands to reason that to be a successful business analyst or systems analyst in a low-code or no-code environment, you must design process configuration models based on sufficiently detailed logical requirements, that you have elicited and understood.

 

How to Choose Your Next Process Model’s Degree of Abstraction

Follow these guidelines to choose what the required degree of abstraction of your next process model will be:

Use conceptual process models to get agreement about and communicate what the process is. What is the scope? What causes it to be performed? What are the activities and their expected sequence? What is or are the expected outcome(s)? Use conceptual process models for planning, scoping, and architecture definition.

Use logical process models to get agreement and communicate how a process works or is required to work. Be prepared to elicit and document the answers to logical details such as: What are the detailed or summary activities? Who is responsible for what? What happens if? What happens when? What decisions will be made? What information is produced or used? Remember to elicit and include the details that are relevant to your model’s intended audience: those who participate in the lifecycle of your business process management or information technology project. Keep your model’s intended audience in mind when eliciting and documenting details. Use appropriately detailed logical process models for detailed functional requirements or design.

Use process configuration models to specify the configuration of concrete software modules, physical devices, and/or manual operating procedures that implement a process.

You typically use process configuration models in no-code or low-code software generation. To gain the benefits, you must specify very precise and accurate process implementation details, and exactly follow the process configuration modeling syntax.

 

Conclusion

A process model is not just a flowchart. It communicates what are, or will be, real-world operations. It may play a crucial role in the success or failure of your next business process management, information technology, or regulatory compliance project.

The most competent business analysts and process analysts clarify what their model’s required degree of abstraction will be, at the start of their analysis. They then focus their own and their project stakeholders’ efforts and time on the types of model content and format that will best suit each project’s unique needs.

You are welcome to learn more or share your comments and experiences about Your Next Process Model’s Degree of Abstraction via the Contact Us page at www.ProcessModelingAdvisor.com.

Copyright 2023, Edmund Metera
[1] The Business Analysis Standard (IIBA, November, 2022)
[2] PMI Guide to Business Analysis (PMI Inc, 2017)
[3] The Universal Process Modeling Procedure: The Practical Guide to High-Quality Business Process Models (Metera, 2018, 2022)
[4] The Universal Process Modeling Procedure: The Practical Guide To High-Quality Business Process Models Using BPMN (Metera, 2022)
BATimes_Mar9_2023

Delivering Analysis: Working With the System

Written by Anna Rajander on . Posted in Articles.

Business analysis is an evolving profession characterized by change. However, not all businesses embrace evolution and change in the same way. This can result in business and delivery practices constraining the use of newer, more agile approaches to business analysis. This article presents some ideas and techniques to help business analysts identify, understand, and work with constraining business practices.

 

The Challenge

You may have heard the serenity prayer. It goes something like this:

God, grant me the serenity to accept the things I cannot change,
the courage to change the things I can,
and wisdom to know the difference.

The origins of the serenity prayer date back to the 1930s and 1940’s. It is one of the most well-known and quoted prayers in the Christian world, with versions adorning posters, fridge magnets and trinkets across the globe. And while the prayer predates the business analysis profession by decades, the sentiment of the prayer is relevant for many analysts – even those of us who aren’t religious.

Business analysis is a profession of change. Indeed, the IIBA defines business analysis as the “practice of enabling change” in an enterprise. Whether it be learning a new technique or method, or applying skills to a new business domain, business analysts are encouraged to constantly experiment, learn and adapt. We are often looking for opportunities to apply new skills or techniques, or engage with enterprises that are using newer, more agile delivery methods. This constant exposure to change can make business analysts very comfortable with change.

It can therefore be frustrating when we find ourselves in environments where prevailing business practices prevent us from delivering analysis in the way we would like. Outdated systems, over-zealous governance, rigid templates and document heavy processes can constrain our ability to used more modern, agile delivery methods and techniques. And inflicting change on stakeholders using outdated delivery practices can seem like a double standard! Yet, working against such practices and processes can cause even more problems, resulting in business resistance, conflicts with stakeholders, delays, and even failure to deliver.

 

Advertisement

 

Identifying Constraining Business Practices

Business analysts need to fully understand the business context in which they are delivering change. This includes understanding the business and delivery practices being used to define, design and implement change, and how they impact business analysis. Early identification of constraining business and delivery practices gives business analysts an opportunity to find ways of working with them – rather than against them.

There are several common business analysis techniques that can be used to help identify and understand restrictive business and delivery practices. For example:

  • SWOT Analysis – A SWOT analysis can be used to help identify business practices that may impede or constrain business analysis activities (in other words, are a threat to the delivery of good analysis), identify opportunities to improve business practices, and identifying any strengths/weaknesses that may help/hinder delivery given the constraints.
  • Process Analysis and Modelling – Understanding when and how analysis activities will engage with constraining business practices can support the creation of efficient business analysis plans that meets all delivery requirements.
  • Stakeholder Analysis – Remember the saying It’s who you know – not what you know? This is too often true – particularly when it comes to governance and approvals processes. Understanding who the influential stakeholders are and engaging them early can often alleviate and even remove constraints.
  • Root Cause Analysis – There is usually a reason why things are done the way they are, although it may not always be obvious. Uncovering that underlying reason for a given business practice can help analysts a) identify areas for improvement, or b) accept it for what it is.

 

Conclusion

Understanding business and delivery practices that constrain business analysis can help analysts:

  • Identify and champion opportunities for business improvement
  • Identify ways of working with or within existing business practices that may better support analysis, or
  • Accept and work with prevailing business practices as efficiently as possible.

To paraphrase the serenity prayer – accept the things you cannot change, change the things you can, and understand the difference!

 

Anna Rajander, Dec 2022
Resources:
  1. Serenity Prayer – Wikipedia, accessed Dec 2022.
  2. A Guide to the Business Analysis Book of Knowledge (BaBOK) v3, IIBA, 2015.
BATimes_Feb22_2023

Top Business Analysis Skills To Learn in 2023 To Thrive in a Volatile Economy

Written by Ananya Pani on . Posted in Articles.

With the economic landscape ever-evolving and uncertainty in the air, it pays to know which business analysis skills are essential for success. In such a business environment, having the right skills can be the difference between success and failure. As 2023 approaches, it’s more important than ever to develop the right business analysis skills that will help you stand out from competitors and thrive in these uncertain times. With new technologies and approaches emerging all the time, developing the right business analysis skills has become more important than ever before. In this article, we’ll explore the top business analysis skills you’ll need to master in order to stay ahead of the pack. Find out how you can get ahead of the curve by acquiring these valuable skills now!

 

 

What is Business Analysis?

The term ‘business analysis’ is used in many different ways, but at its core, business analysis is all about bringing positive change, improving business performance with technology adoption, Process improvement and removal of inefficiencies in the cycle. It also encompasses improvement of revenue, market reputation, user experience, understanding how businesses work and how they can be improved. It’s about finding ways to do things better, faster, or cheaper.

Image Source – Freepik.com

Business analysts typically have strong analytical and problem-solving skills, and are able to see the ‘big picture’ while paying attention to detail. They need to be good communicators, great facilitators as well as collaborators, able to explain complex concepts in simple terms, asking the right questions and also be good listeners.

As businesses become more complex and the pace of change increases, the need for business analysts will continue to grow. If you’re thinking of a career in business analysis, or are already working as a business analyst, it’s important to stay up-to-date with the right skills, latest methods and tools.

Essential Skills for Business Analysts in 2023

As the world economy becomes increasingly volatile, businesses must be agile and adaptable to survive. Business analysts play a vital role in helping organizations in changing gears, understand and respond to change and adapt to the new business needs. In 2023, the most successful business analysts will be those who have developed the following essential skills:

 

Image Source – Freepik.com

Data Analytics: With the increasing amount of tech penetration and the huge amount of data available, business analysts are expected to be skilled to interpret, analyze data, see patterns in them and come up with actionable insights from them. To be able to do all this they need to be proficient in data analytics tools and techniques such as data interpretation and visualization. They will need to be able to not only interpret and communicate the results of these analyses to key stakeholders but also present actionable insights for strategic decision making.

 

Image Source – Freepik.com

 

Agile methodologies: Agile methodologies have proven to be effective in adapting to change, taking

frequent customer feedback and prioritizing delivery accordingly. And as a result, today more than 70% projects adopt agile methodology and their adoption will continue to grow. Business analysts need to be conversant with the principles of agile analysis and be able to work effectively within agile teams.

 

Advertisement

 

Financial Analysis: In a volatile economy, it is important for business analysts to understand financial analysis and be able to assess the financial impact of different business decisions. They will need to be able to evaluate investment opportunities, assess risks involved, and make recommendations based on financial data. They need to have the ability to know which are the initiatives that can help in quicker turn around for revenue and which changes can bring cost control thus making a better cash flow situation for the organization.

Image Source – Freepik.com

 

Strategic Thinking: Business analyst as a role requires higher level of thinking as well as attention to details to see the opportunities of improvement. Hence, they will need to be able to think strategically about the long-term goals of the organization and be able to develop plans to achieve those goals. They will need to be able to evaluate the potential impact of various business options and make recommendations based on data and best practices.

 

Adaptability: The ability to adapt to changes in their environment is a critical skill for success in a volatile economy. Business analysts will need to be able to quickly respond to changing conditions, be flexible to acquire skills to perform well in their approach to solving problems.

 

Cross-functional Collaboration: Business analysts are the change makers bringing positive changes to the organization thereby making the organization’s process faster and better. To achieve these objectives, they will need to be able to work effectively with teams from different departments, hierarchy, backgrounds, and be able to translate technical concepts and requirements into language that is accessible to a wide range of stakeholders.

Image Source – Freepik.com

 

Communication Skills: Business analysts are the ones who are required to influence stakeholders and users to come to agreement for the business decisions, and this requires being a great communicator. Effective communication is and will remain a critical skill for business analysts in 2023 and years to come. They will need to be able to clearly and effectively communicate complex ideas and data to stakeholders, and be able to negotiate and manage conflicting interests.

 

In conclusion, the skills that business analysts need to focus on in 2023 will continue to evolve, but the skills outlined above will likely be critical for success in a volatile economy. It’s important for business analysts to stay up-to-date about emerging trends and to continuously grow their skills and knowledge to stay ahead of the curve.