Business analysis in continuous delivery

In projects that require frequent delivery, constantly collecting user feedback, embracing changes, and pursuing business agility, software development and delivery are iterative. In such a project team, BA (Business Analyst) usually needs to complete the analysis of this iterative development task before a development iteration starts. However, in special cases, the cycle from collecting customer requirements to communicating feature details to the development team is shortened to one to two days. Ba can be used for thinking and analysis for much less time than any waterfall project that can be designed in advance.

Related vendor content

Sybase online seminar: New Features of Sybase iq15.3, a columnar database in the cloud era (Monday, August 22)

Baidu technology salon No. 17th: javascript framework in the rich client era (Saturday, August 20)

2011 System Architect Conference grand invitation for attention

Baidu World 2011 conference, opening at the National Convention Center on September 2! Free registration in progress!

Infoq is looking for: Planning and editing, Project Manager, Business Manager, etc.

In such an Agile Project, how can ba adapt to this delivery model, complete high-quality business analysis, and coordinate teams to deliver high-value software to customers?

Project Background

ABC is a well-known international accounting firm with a large business scale and branches in more than 170 countries around the world.

Thoughtworks was invited to provide IT solutions and software system development for its international assignment service. The system includes collection of tax return data for employees dispatched globally by their customers, and business processes for managing ABC tax consultants to review, calculate, and generate reports on such data; gradually replace legacy systems that are far from meeting business and performance requirements.

There are two main types of users in the system. One is the employees (hereinafter referred to as Mary) of ABC customers who are dispatched to work in different countries. These employees use the system to fill in the data required for tax return. Another user is ABC's tax consultant (Kim), responsible for reviewing and processing data submitted by Mary.

Main challenges faced by BA in this project

• The project is distributed development. The decision makers of ABC are in the United States, while the development teams of thoughtworks are in China, and the communication and feedback cycle is sometimes long.
• Because ABC attaches great importance to user experience, it is necessary to deliver software frequently to collect user feedback and adjust solutions and subsequent development plans in a timely manner. This greatly shortens the collection requirement, analysis, and development cycle, and increases the risk of defects in the analysis.
• When problems are found during the development process, you cannot communicate with the customer immediately, and the development progress may be affected.

Identify Business Value

The importance of business analysis is to do the right thing first. Understanding the customer's business and paying attention to the value behind the demand can help the project team make the right choices in software design.

The difficulty we face is that the customer's requirements are usually direct software functions, rather than business problems that need to be solved. If Ba only focuses on system analysis of the features required by the customer, it will lose the opportunity to help the customer optimize the solution and improve the business process.

How to find business value?

Taking the user stories in Agile development as an example, a simple way to find out the customer's business problems is to summarize the content of each user story in the following ways:

As... (Role), I want... (What kind of function is completed), so that... (What issues are solved and what benefits are brought)

"So that ..." It illustrates the Business Value of the story, that is, the business problems to be solved. Accurate search for business value will help us design the most appropriate "I want to", which may be better than the functional requirements directly put forward by customers.

Note that you should not regard the solution or function as the value of the user story. Taking a user story in ABC's business system as an example, BA's understanding of the business value of this requirement directly affects the advantages and disadvantages of the solution.

As (...)	I want (I want ...)	To (So that ...)	Are values clarified?
Mary	View my travel statistics in real time	Learn about my stay in various countries or regions and activities	No
Mary	View my travel statistics in real time	I can quickly check whether I have entered correct data on stay time and activities in various countries or regions (to ensure that I can submit accurate tax return data as required by law)	Yes

In the two different expressions of the user story, because the first statement only describes the required functions and does not describe the business value, in the function design, we may waste designing the content of "Travel Statistics" too detailed, so that users do not understand the intention of this function. The business goals stated in the second statement are very clear, which can help us design suitable solutions more easily.

In addition, when understanding the customer's business problems, BA is best to ask the customer to provide some real cases/scenarios to confirm their views and deepen their understanding.

Avoid analysis errors

In actual work, we found that the following two aspects of analysis work are easy to be ignored by BA, and the wrong decision is made.

1. The customer requires that the functions of some existing business processes or legacy systems be implemented

   For example, a feature that the customer needs is a feature that has been used for many years in the current legacy system and has not received any complaints. Therefore, customers and Ba often think that this function is reasonable and ignore in-depth analysis and thinking. However, a decision that is not comprehensive may conflict with the foreseeable new function.

   In the legacy system of ABC, the questionnaire content used to collect tax return data is maintained through an Excel table, while Mary downloads the Excel questionnaire at the front-end and then uploads it after filling out the questionnaire.

   In the new system, the questionnaire is changed to the online method, and other necessary functions are used to improve Mary's user experience and satisfaction. However, because the employees of the customer are financial backgrounds, they like Excel tables very much. However, the maintenance of the questionnaire with Excel tables has proved to be very effective, therefore, the customer insisted on using this method in the new system. After careful analysis, we found that after the new feature is launched to improve the user experience of Mary, using EXCEL tables to maintain the questionnaire content will greatly increase the maintenance workload and error rate, this is contrary to the related objectives of the project. After listing the details of the problem, thoughtworks persuaded the customer to adopt a new solution.

2. Customers require the use of new IT systems to change the current business process

   The customer finds that the current business process is unreasonable and wants to directly change these processes in the new IT system. Without careful analysis, this approach may be very dangerous, and blind changes to business processes may cause trouble for some users, forming a strong resistance for customers to implement the software. So it is important to understand the values and causes of these processes, so that we can provide customers with scientific IT solutions to gradually optimize their processes.

In ABC's business process, some communication between Kim and Mary is completed by email. There are two business risks here: 1) important information exchanged between Kim and Mary is dispersed in their respective emails, which cannot be recorded by the system and cannot be divided into responsibilities in case of legal problems; 2) kim and Mary may use an email to send confidential content. If an error is sent, the consequences are unimaginable.

When developing a new system, the customer asked us to add a message function so that the communication between Kim and Mary can be conveniently completed within the system. After the feature was launched, the two business risks were well resolved and good feedback from users such as Mary was received. However, this has had a significant impact on the work of Kim users in some country branches. With the previous use of the mail system, Kim can forward Mary's mail to relevant colleagues and track the results using the rich features of the mail. The new message function does not meet all the requirements of emails, so it increases the difficulty of their work. In addition, due to Mary's favor for this function, the number of messages sent far exceeds the number of emails sent when the legacy system is used, it exceeds the cost that customers can afford in the short term to increase Mary's satisfaction.

When we encountered the above problems, we analyzed with the customer and proposed a compromise solution, which integrated the message system with the customer's email at a low cost, at the same time, it helped the customer develop a blueprint for improving the business process and supporting IT solutions.

Clarify the demand priority

In projects that are frequently launched, one of the most important practices is to determine the priority of the requirement, so that important functions can be developed and put into use in a timely manner to collect user feedback. The general practice is to require the customer to set the priority of the requirement, and then work out an iterative development and launch plan together with the project members. However, due to the limitation of the role and thinking angle of the customer's decision makers, the priority rating may be blind. We recommend that ba evaluate the priority by referring to the following value dimensions.

Analyze the demand priority from the Customer Value Dimension

Demand value dimension analysis chart

Value Dimension	Description
Vision and objectives	Does this function fit the project's vision and business objectives? The higher the degree of fit with the project objectives, the higher the priority.
Time Limit	Does the customer's business have a certain schedule? If the function must be put into use before a certain time point, the requirement must be included in the release plan of the corresponding time point.
Selling points	Is this feature a selling point that attracts specific target users? If the customer's funds are faulty or need to be quickly recognized by the market, you can consider placing the demand as a high priority.
Alternative?	Is there a convenient alternative to this function? If there is a simple alternative, this requirement has a lower priority
Customer's internal political factors	Is there a political factor in the customer's internal function? For example, if a function only provides value to a small number of users, but determines the investment and Evaluation of an important organization within the customer on this project, you can consider setting this requirement as a high priority.
Investment income	Does the development cost of this function point match the benefits that customers can obtain? For example, a customer's workflow wastes a large amount of time for a group, but it does not affect other departments or work processes. If the investment caused by developing the corresponding software functions is greater than the money that the customer can save in a certain period of time, the demand has a lower priority.
Technical dependency	Are other requirements dependent on this feature? If the priority of the function is higher, the priority of the function should be higher.

Impact of technical risks on priority

In addition to the customer's deciding factors, we should also consider the impact of technical implementation. If some features with high technical risks can first enter the development stage, the problem will be exposed as soon as possible. Solving these problems in the early stage of the project helps reduce development costs. Therefore, in addition to the above customer value dimensions, we should refer to the following matrix to weigh the priority of the demand.

Demand priority Matrix

The Customer Value Dimension and demand priority matrix are not a priority calculator, but a tool for communicating with customers and teams. Different projects have different impact dimensions. Due to the complexity of various factors, the Customer Value Dimension and technical risk factors need to be considered comprehensively, and the weight cannot be calculated. Ba can reach an agreement with the customer on the content of the above factors, so that the customer can quickly and accurately determine the priority of the customer's needs. At the same time, through the analysis of the value dimension, we will have the opportunity to clearly understand the reasons for the high or low functional priority, so that we can accurately compile the project development and launch plan, and reasonably divide the scope of user stories.

Manage customer expectations with value dimension analysis

Some customers' decision makers may prioritize projects based on their preferences, which may pose a certain risk to the project's successful delivery by target. In addition, the customer can easily pursue perfection for a single function during the function design and acceptance stages, resulting in additional work and increased project scope. This part of extra work may be inappropriate or of low value. In the long run, the team will gradually deviate from the project goal during the development process. If you can use the priority dimension to analyze these additional requirements, you can provide a more convincing basis to help customers make correct decisions and achieve effective management of customer expectations by the BA and project managers, this reduces delivery risks.

Play the role of other team members in Business Analysis

In projects with frequent delivery, if BA undertakes business analysis independently, omissions may inevitably occur. Thoughtworks has worked with ABC's IT department to complete some integration of its business system. During the cooperation, we found that the IT department developers of ABC company had a low level of engagement in business analysis, resulting in the following problems:

1. Ba needs to write a large number of requirements documents, so the period from Requirement Analysis to Software Delivery is long.
2. Design defect discovery lags behind
3. If frequent delivery is required, the solution quality is poor and the solution optimization capability is weak.

Thoughtworks developers have a high degree of engagement in business analysis, effectively avoiding the above problems.

How developers participate in Analysis

Developers are the implementers of software functions and have a relatively accurate estimation of the implementation workload of the solution. After clarifying the project objectives or business problems, if Ba can analyze the solution together with the developers, it will more effectively find cost-effective solutions for customers.

After the customer's requirements are collected, Ba can analyze the needs based on the business value to determine whether the functions or solutions proposed by the customer can meet the business value or the business problems to be solved; you can also design functions or solutions that meet the business value according to your own understanding.

After completing the above work, BA should fully communicate with developers on the needs and business values, verify the feasibility of function implementation, and actively explore better methods. If developers propose different solutions that suit the business value, Ba can ask developers to provide comparative data on development workload, advantages and disadvantages, and technical risks, this helps you effectively communicate with the customer and select the best solution. You can even help the customer adjust the priority of the requirement based on the analysis results. For features that are technically difficult and highly risky, we recommend that you invite senior developers to participate in the discussion.

Challenges and Solutions encountered during communication with developers

As the above method requires a lot of communication with developers, some BA also encountered the following challenges when applying the above practices.

1. Developers lack enthusiasm for participation in business analysis

   In thoughtworks, most developers like to actively think about and provide help for business analysis, greatly reducing the vulnerability in demand analysis. However, in the IT department of ABC, developers seldom take the initiative to make plans for business analysis, especially for junior members in the team, and are unwilling to participate in solution discussions. The advantages of team members are not fully utilized. Developers only work hard as needed. The problems of result functions and solutions are often exposed in the test or acceptance phase, which inevitably leads to waste.

   From the perspective of developer growth, from the perspective of thoughtworks practice, actively understanding the business and thinking about solutions can improve technical capabilities faster. Therefore, Ba can find some practical cases, coordinate with the project manager to communicate with all team members, encourage everyone to actively participate in business analysis, and gradually form a good atmosphere for developers to collaborate with BA.

2. Developers can easily argue about customer needs or solutions

   When developers are actively involved in the analysis process, they sometimes find flaws in the value of software functions and have a lot of arguments with BA in details, the failure of Ba to cope with developers' problems and to verify the answer with the customer.

To solve this problem, you can use the following methods:

• When collecting requirements, BA tries its best to fully understand the customer's business problems, so as to quickly answer developers' questions.
• In the face of developers' doubts about the solution, we should maintain a good attitude and clearly understand the problems and causes of developers' concerns.
• If the information you have mastered does not prove the rationality of the current solution, you can work with developers to find a better solution and compare the advantages and disadvantages with the current solution.
• Communication between the new and old solutions and customers can help customers quickly make judgments

Do not ignore the contribution of testers in Business Analysis

Because of the tester's angle and attention to the details, we can often find some functional details of the design vulnerabilities. Therefore, before a user story enters development, the BA should fully communicate with the Quality Assurance personnel on the relevant business values, and will create an opportunity for the BA to correct design defects before the function enters development.

As a Quality Assurance personnel, if you fully understand the business value behind the function, you can write more comprehensive test cases to improve the test coverage rate. This serves as the final step for delivering high-quality software.

Conclusion

Business analysis is difficult, especially when we are facing unknown fields. If we simply develop software based on the customer's specific needs, the value we deliver to the customer will be very limited. However, identifying the business value, helping the customer analyze the demand priority, and ensuring team collaboration will effectively improve the team's software design capability, solve the customer's real business problems, and deliver greater value.

As a business analyst, when you try the above practices, you may find that you have a deeper understanding of the customer's business. In the communication with the customer, it is easier to put forward valuable questions and suggestions, so as to enhance the customer's trust in the project team and lay a good foundation for successful project delivery.

* Note: Li Guanglei, consultant at thoughtworks, proposed the concept of "Customer Value Dimension. I would like to express my gratitude to Li Guanglei.