Chapter 12.

Case Study: Inception Phase

To better understand how to successfully initiate a Disciplined Agile Delivery (DAD) project
were going to work through a fictitious case studythe AgileGrocers1 Point of Sale (PoS)
system. This case study is based on a similar project Mark was involved with although the names
and details have been changed to protect everyones privacy. The focus of this chapter is the
Inception phase for the PoS system; later chapters explore the rest of the project in detail. Note
that this is only one potential way to initiate a DAD projecttailor your approach to reflect the
realities of your situation.

Introducing the AgileGrocers POS Case Study

On a Wednesday, Mark meets with Dean, the VP of Store Operations for AgileGrocers
International, a retailing company that has 250 grocery stores across Canada.

Dean: Our store managers have been complaining about the fact that our point of sale systems
are old. They also mention that customers have been complaining about long checkout lines. I
have some money in my budget to upgrade the store systems, but I am not sure whether the
investment would be worthwhile. I am not sure what they really need and what I will get for my
money.

Mark: Why dont you give me a week to outline a solution for you? You will then have a better
understanding of what the real problem is, what the solution alternatives are, and what it would
take to implement the best solution.

Dean: Just a week! Surely that is not enough time. Traditionally we have spent three to six
months doing planning and writing detailed requirements documents. I have usually ended up
spending a good portion of my budget on these documents while not seeing anything of real
value in the meantime.

Mark: Well we are going to use a more modern approach to building solutions that does away
with unnecessary work that delays delivering value to you, the stakeholder. This approach is
called Disciplined Agile Delivery. It is a process framework that we use to guide our team in an
efficient, yet disciplined fashion. Using this approach, there are very few surprises for you. You
will quickly see your solution evolve before your eyes and have the opportunity to adjust what
you want as we go.

Dean: Sounds interesting. Okay. Lets see what you can get done in a week.

Mark: Great. I need to spend some quality time with someone who can properly represent your
business needs. He or she should understand the challenges you currently face and can help
articulate what a good solution would look like. I also need to spend some time with an expert on
the companys architecture.
Dean: I know just the people. Louise knows our business very well and is available to your
project. If she does not have the answers, she can definitely get them quickly. Terry is our
enterprise architect who could free up some time to spend with you next week. Bob understands
the systems ops side.... But, theyll only be available 3 hours a day because....

Mark: Okay, I didnt expect them to be available full time anyway. We have project-related
things such as envisioning the architecture, getting the workspace set up, and so on. Well be
doing that stuff when your people arent available to work with us. But when they are with us
they need to be prepared to be focused, to make decisions, and make trade-offs all in a timely
manner. One more thing. We should assemble a cross-functional team of developers to set up
their work environment and do some estimating.

Dean: Doesnt the project manager do the estimating?

Mark: Actually, modern agile methods understand that the best estimates come from those
committed to actually doing the work.

Dean: That seems a bit strange to me; Ill have to see it work. Ill assemble your development
team immediately. But I dont think theyve heard about this agile thing before. Maybe we
should just do things the old way.

Mark: Well part of my job as the agile team lead is to act as an agile coach. I will spend some
time with them this week bringing them up to speed with key aspects of the DAD framework.
Dean, you are a busy man, so as soon as I get back to my desk I am going to book some time
with you for next week to review the results of this phase and determine next steps.

Dean: Okay, well dont get carried away. I am not sure whether it makes sense to change any
systems in the stores at this time. I really dont know how a new system is going to fix our
problems. So well see what kind of business case you can come up with in a week, before I
commit to funding anything further.

The next day (Thursday) we decide to run a one week effort (the Inception phase) starting next
Monday. Mark and the team need to create a business case and plan for implementing a solution
for Deans business problem. We also need to set up the environment and get the commitment of
people and resources. This is not trivial and is a challenge to finish quickly. To get ready to start
on Monday, Mark meets with the product and architecture owners to get buy-in to the approach.

Mark meets with Louise, the candidate product owner to discuss her involvement in the project.

Mark: Hi Louise. I am very pleased that you have decided to join our project.

Louise: Actually, I was volunteered to join this project. I have a lot of work to do already. I
have training sessions with new store managers and need to prepare some new materials for
these sessions. Hopefully this project wont take much of my time.

Mark: Well, Louise, we do need you full-time on this project if we are going to be successful.
Louise: That is not possible. Can I send someone in my place for these meetings this week?
Since we are just doing planning this week, the project hasnt really started yet.

Mark: While we are not starting to build the solution until the week after next, the decisions on
the scope and vision of the solutions are extremely important. Dean says that you have the best
understanding of the current problems in the stores and already have expressed some ideas for
the new point-of-sales systems. How about we hold the visioning sessions from 10:00 a.m. to
1:00 p.m. each day next week and I bring lunch in?

Louise: I hate to give up my lunch time, but if you limit it from 11:00 a.m. to 1:00 p.m. I suppose
I could adjust my schedule.

Mark: I guess that is a reasonable compromise. This way we can minimize your time initially
and have time to summarize your feedback and create some minimal documentation to describe
the vision for what we are going to build.

The discussion turns to setting up a work environment:

Mark: Louise, we need a common work area. Our small team of eight people should all relocate
to a common room and work there side-by-side. Can we have room E for this?

Louise: I dont think that is possible. The business analysts use that room for meetings with the
users. We do lots of slide presentations, process diagramming, and discuss requirements and
issues. The analysts then go back to their cubicles where they can work in peace and quiet to
document the results of the meetings. They then schedule more meetings to review the
documents. I know that the analysts would not want to work together in the same room.

Mark: I know that this is a new approach, but we know from experience that if our customer
representatives such as yourself work together with the development team, the need for these
meetings and the extensive related documentation is reduced dramatically. Lets try it. If it is not
working, we can discuss alternatives.

Louise: Okay, but I dont think this will work.

Mark: I understand your skepticism, but let me promise to show you a new way of working next
week when we get into developing your solution. Rather than trying to explain it now, it will
make more sense when you see it in action.

Louise: Should we start your planning sessions on Monday?

Mark: Yes, lets. I will also invite Terry, the architect, to these meetings. It will be fun.

Later that day, Mark meets with Terry, the enterprise architect:

Terry: I understand that you are moving our developers for this project into one room. They
wont like that! What are your requirements for the room and workstations?
Mark: Ideally the team should have notebook computers with wireless access to the network.
They should have tooling that supports instant messaging. This will allow us to get instant
answers to questions in the event that a team member is working outside the work area or offsite.

Terry: Our new tooling allows us to run constant builds and automated tests as we craft your
solution. It allows us to also plan and track our work. Do we need a separate defect tracking tool?

Mark: For the approach that we plan to use, surprisingly no. Our development tool supports the
ability to track defects as work items and that is all we need for now. I will explain when we get
into the next iteration.

Terry, we are going to designate one of the developers on the team as the architecture owner.
They represent your enterprise architectural vision on the project. This needs to be someone
familiar with your organizations standards as well as what other enterprise assets are available
to leverage or reuse.

Terry: Pete would be ideal for this role. I have worked with him closely for the last couple of
years. I will make sure that I touch base with him regularly to ensure that he gets everything he
needs.

Developing a Shared Vision

The following Monday Mark (team lead), Louise (product owner), and Pete (architecture owner)
get together with Dean (project sponsor) to outline the business problem to be solved and to
envision a candidate solution.

As a facilitator, Mark helps the assembled team put together a snapshot for the business case of
this project.

Mark: Dean, what information do you need to help you make a decision on whether to invest in
this project?

Dean: I suppose I would like a basic understanding of the following before I can dedicate more
dollars to this project:

What is the business problem? The symptoms and root causes? What happens if we dont
change?

What is the suggested solution? How does it address the business problem?

What are the key needs and benefits (features) of the proposed solution?

How long should the project last? At what point is the solution provided to the end users?

What does the architecture of the solution look like?

 How long will this solution last? Will it need new features or an upgrade to a newer technology
soon?

Mark: Wouldnt it also be useful to capture a list of the projects highest risks that could
jeopardize delivery so that we can proactively take steps to mitigate them before they arise?

Dean: Yes, I suppose that would be useful. This seems like a lot of information. So I dont know
how you can possibly do this in one week!

Mark: This may look like a daunting list. However, we are not looking for exhausting
descriptions of the above. No amount of documentation written up front will accurately represent
what our stakeholders want. The truth is, they will not know exactly what they want until they
see it. Likewise, the delivery team will not know how long it will take to deliver the system until
they get some experience building increments of the solution. So this is why we are spending a
timeboxed week to get enough information to justify pushing the boat out to sea. We will quickly
begin to steer as we get into the Construction phase iterations and form a common understanding
of our true destination.

Dean: Okay, lets give it a shot, but it sure sounds like lots of meetings and documentation to me.

The team decides to jump in and create some work products to answer the above questions. To
describe the business problem and outline a proposed solution with a list of features, they choose
to create a short vision statement. The vision statement has been a popular work product of the
Unified Process for many years. However, on our DAD project, we choose to capture the same
information in a more streamlined fashion. Following is a summary of the key vision information
that the team captured.

Vision for AgileGrocers New Point of Sale (POS) System

AgileGrocers is a grocery chain with 250 stores across Canada. Thee stores have not had any
updates to their store cash register equipment and software for more than ten years. The cash
registers are continually breaking down and frustrating the cashiers. Lines are unacceptably long
because each purchase transaction takes too long.

In the grocery industry, there is a trend to allow customers to check out their own grocery
purchases. This reduces the need for cashiers and the cost saving can allow us to open up more
checkout lanes. This vision statement describes the need for the new system as well as the
proposed new functionality.

The team spends some time on the whiteboard mind mapping symptoms and root causes for the
pain that the stores are experiencing with their current system. The salient points from the mind
map, see Figure 12.1, were then captured as part of the vision statement (see Figure 12.2).
Figure 12.1. The mind map

Figure 12.2. Capturing the business problem in the vision statement

The team decides that as they proceed with implementing the solution they need to ensure that
key stakeholders are kept informed and allowed the opportunity to guide the team toward the
most effective solution. They therefore quickly list their key stakeholders in the vision statement,
as shown in Table 12.1.
Table 12.1. Listing Key Stakeholders as Part of the Vision Statement

The team next does a brainstorming exercise to determine the business needs related to the
problem. During the session, Louise says, we need to track average cashier transaction time!
Mark suggests that this may be a good feature, but lets first concentrate on the business needs,
before we start to identify system requirements. Mark suggests that perhaps the business need in
this case is to track cashier productivity. We can decide how exactly later. Figure 12.3 depicts
the list of needs identified by the team during their brainstorming session.
Figure 12.3. Needs identified during the brainstorming session

Now that we have a list of business needs that would address our business problem, Mark leads
the team through an exercise to brainstorm stories and features that would address these needs.
They associate each story with a need that it fulfills. This helps us to avoid dreaming up features
that are not related to a basic need of the solution. By doing this we can avoid scope creep with
wants versus true needs.

The architecture owner Pete reminds Mark and Louise that we need to remember to capture the
quality aspects of the solution (also known as nonfunctional requirements), such as expected
system performance. Some of these ideas become sticky notes. Figure 12.4 shows a picture of
the stickies from the brainstorming session that have been posted on the whiteboard, organized
with their related needs from the previous exercise.
Figure 12.4. User stories/features to satisfy the needs

The needs and features from the sticky notes are quickly added as a list in the vision statement
and are summarized in Figure 12.5. While a classic vision statement captures the key capabilities
as features, we chose to write most of them in user story format. Notice that one of the features
on a sticky note is user friendly, which is a famously popular but ambiguous requirement. We
captured the request from Louise during the brainstorming, but knowing that this is not testable
as written, we made it a testable feature as shown in the list of needs and features in Figure 12.5.
Figure 12.5. Product overview within the vision statement

Dont Worry About Consistency of the Wording

The feature list in Figure 12.5 isnt worded consistently. Sometimes it talks about a solution and
sometimes a system. Sometimes a feature is worded as a formal shall statement, and sometimes
its merely a statement. Sometimes The system shall . . . and sometimes System shall . . . .
The important thing is that the information is being sufficiently captured so that it can be
understood. Both Mark and Scott have been involved with projects where incredible amounts of
effort were wasted to ensure dubious levels of consistency within the documentation, which
added no practical value to the organization.

After creating this initial list of stories, the following dialogue occurs among the team:

Louise: This looks like a great list of stories for our new system. However, Dean has asked me to
remind you that we only have a staff budget of $400,000 for developing this system. Hardware
and software are in addition to this amount, and naturally we need to be smart about that too.

Mark: Thanks for letting us know, Louise. This is a constraint on the solution and is useful to
know.

Pete: We will have to make some compromises on the architecture to bring this in on budget. I
dont believe that 2 second response time is possible given the hardware that we will have to use.
I think that 3 second response time is a more reasonable expectation.

Louise: Well, I dont like it, but I suppose we all have to make compromises.

Story 4 is then adjusted to 3 second response time as a result of this conversation.

A key point is that constraints are useful to identify at the beginning of the project so that
expectations are reasonable about what is achievable given the constraints. Table 12.2 shows the
constraints that the team identified and listed in the vision statement.

Table 12.2. Constraints for the AgileGrocers PoS

DAD recognizes that agile project teams seldom work in a vacuum. At times they may be
constrained by organizational standards such as those defined by architecture and database
authorities. The table of constraints includes a requirement of the team to collaborate with the
enterprise architect to ensure that opportunities for reuse are identified. These types of
constraints are a good thing.

Louise: I am pleased to hear that we will be conducting demonstrations of the solution at the end
of each iteration. Will sign-offs be required for these demonstrations? Perhaps we should note
that in the vision?

Mark: That is a good point, Louise. While we are indeed conducting demos, we try to minimize
sign-off as much as possible as they can slow down the team. However, what we should talk
about now is quality of service requirements related to the solution. We need to determine what
your criteria are for accepting stories implemented in an iteration as complete.

Louise: That is easy. All the requirements need to be implemented for each story, and they need
to have zero defects.

Mark: I would suggest that if we wait for all defects, no matter how trivial, to be fixed, we will
not be able to complete the stories at the end of each iteration. We will continue to discover and
fix minor defects from all stories as we move through the iterations, so lets compromise on the
quality expected at the end of the iteration for the stories that are developed.

After further discussion, the team agrees on conditions of satisfaction for the stories, documents
them in Table 12.3, and adds it as a section in the vision.

Table 12.3. Conditions of Satisfaction for Work Delivered at the End of Each Iteration

We produced the preceding information for a brief vision statement over the course of two
sessions over lunch, for a total of 4 hours.
Vision Statements and Portfolio Management

For our case study, we chose to enter the Inception phase with nothing more than a conversation
and understanding that we should do something about a perceived business problem. This is of
course from our point of viewlong before our project began Dean had lobbied the CIO for a
better solution, they discussed several strategies, and then the CIO initiated this project. Some
organizations, though, go into Inception with some business case or document like the vision
already completed. In fact, they may use these documents as the method to select projects using a
portfolio management approach. If you indeed have this information going into Inception, that is
great! It will greatly speed up this iteration.

Requirements Envisioning

A vision statement is useful for ensuring that all parties agree on what the business problem is
and what a candidate solution could provide. Now, we need to elicit some requirements for the
solution. There are many different ways to visually elicit requirements, including prototypes,
storyboards, brainstorming, and mind mapping. Other ways of eliciting requirements include
traditional techniques such as questionnaires and interviews.

For the AgileGrocers System we decided to create a use case diagram, shown in Figure 12.6, to
help us derive user stories from our list of features. We gathered the team and our domain expert,
Louise, around one of our whiteboards, and spent 20 minutes determining the key goals (use
cases) and users (actors) for our system.2 Tip: It is easy to create a use case diagram from a list of
stories or features that you have already created.
Figure 12.6. AgileGrocers use case diagram
This diagram shows the five key goals of the new system as well as the actors (cashier, customer,
and store manager) that use the system. The new system will support the traditional model of
asking the cashier to process the sale of groceries for the customer. However, we are adding the
capability for the customer to self-check out via a Buy Groceries use case. The diagram also
shows that we need to interact with three other systems (payment authorization, head office, and
scheduler for running nightly jobs).

Mark facilitated the diagramming of this use case on the whiteboard. When everyone agreed it
looked complete, he pulled out his phone camera and took a picture of it.3

Louise: What are you doing? That is not exactly a work of art!

Mark: Agreed. However, I am going to paste this into our vision statement.

Louise: Shouldnt you do it up nice in our McDrawing tool?

Mark: That could take an hour or two to make it look pretty. I think we can all read it, so lets be
agile and use what we have done already and move on.

Is a Use Case Diagram Agile?

A use case model is typically composed of both a diagram like the one shown previously in
Figure 12.6, as well as a textural specification of the workflow for each of the use cases. These
workflows can be written at various levels of detail depending on your preference. However, to
be as agile as possible, we chose to do the diagram only for the purpose of clarifying the key
users and goals of the solution. Mark finds that such a diagram can help to ensure that we have
proper coverage of user stories such that we have stories to deliver each of the required goals.
He has found that without this diagram, stories representing key functionality can easily be
missed. Scott has found that business process diagrams and data flow diagrams (DFDs) are also
good options for viewing the overall usage of your solution, depending on what your team and
stakeholders are familiar with. Use whatever agile modeling technique you prefer to help flesh
out your stories.

Creating the Ranked Work Item List of User Stories to Implement the Solution

A good place to start building your work item list is to decompose your features from your vision
statement into user stories. Each of the features from the vision statement shown previously may
be too large to implement fully in one iteration. They are also at too high a level for properly
describing and prioritizing the functionality. We therefore decided to decompose each feature
into a set of user stories. For example, Table 12.4 shows some of the user stories that together
fulfill the requirements of the feature A cashier can transact a purchase of groceries on behalf of
the customer in the traditional manner.

Table 12.4. The Start of a Work Item List with User Stories (US) from Feature 1
We made sure to include Pete, our architecture owner, in this session to ensure that we ask him
for possible technical stories such as requiring online backups, fault tolerance, job scheduling,
and other technical requirements to add to our work item list. As we identify each technical and
user story, we make sure that we capture the acceptance tests that need to be passed to consider
the story complete.

Architecture Envisioning

Figure 12.7 shows a simple context diagram4 that Pete sketched on the whiteboard to help
understand what type of information moves between the point of sale terminals, the back office
system in the store, and the head office.

Figure 12.7. Context diagram

In addition to the context diagram, Pete led the team through creating a deployment diagram of
showing the hardware configuration for the store and how it connects to the head office. The
team felt that this was a useful diagram to help understand conceptually how the new system will
look and communicate with the head office. Pete spent 45 minutes using a drawing tool to create
the diagram that you see in Figure 12.8. The team understands that the actual hardware
configuration could change as we learn more about the solution, but this serves to get alignment
on the understanding of how it might work conceptually.

Figure 12.8. Deployment diagram for the AgileGrocers POS system

Pete takes a picture of the hand-drawn context diagram and pastes it into our evolving vision
statement together with the deployment diagram file.

Release Planning

As discussed in Chapter 6, The Inception Phase, during Inception we need to identify the
initial release plan, which is a breakdown of the phases and iterations with start and end dates for
the expected duration of the project. DAD teams deliver potentially consumable solutions at the
end of each iteration. The high-level release schedule for the project is depicted in Figure 12.9.
The team decides to run 12 two-week iterations of Construction. The Transition phase is longer
than a typical project. It will take some time to roll out the new system across all the stores in
Canada, so an eight-week effort is planned for the rollout.
Figure 12.9. Release as a Gantt chart for our new AgileGrocers POS system

Estimating

The estimating for our AgileGrocers system for all the work items in the list came up with a
number of 314 relative points (using the planning poker estimating technique described in
Chapter 10, Initial Release Planning). Table 12.5 shows the same user stories from Table 12.4,
but they now have estimates against each story.

Table 12.5. Relative Estimates for Items on the Work Item List

Identifying Initial Risks

A partial example of the risk list that we created for this project is shown in Table 12.6. Notice
that it is ranked by magnitude, with the biggest risks at the top.

Table 12.6. Example of a Ranked Risk List for the AgileGrocers POS System

As you can see from these examples, it is not necessary to create a lot of documentation in the
Inception phase. However, this minimal information is indeed required to make sure that the
interests of all stakeholders are aligned before we go off and deliver a solution that does not meet
their expectations.

Other Inception Phase Activities

There is more to Inception than producing documents and models. For our AgileGrocers project,
we did a number of activities to prepare the environment for the Construction phase, including

Set up a common work area where the team can work together.

IBM Rational Team Concert was installed for the developers to manage the agile plans, work
items, source code, and builds.

Mark and Scott conducted IBMs three-day Disciplined Agile Delivery (DAD) workshop for
the team to bring them up to speed with agile practices.

The development team participated in the envisioning sessions so that they could develop an
understanding of the solution and the various alternatives that were considered.
Alternative Approach to Running Your Inception Phase

For our case study, we used a set of work products and modeling techniques that we preferred for
the situation. However, you may have your own preferences for how you put together your work
products. Since we strive to produce no more than 20 pages of documentation in an agile
Inception phase we chose to put our work into one document that we call a vision statement. If
this does not work for you, you may choose to put them in several documents such as a Project
Plan, Business Case, or Software Requirement Specification (SRS). The problem with having
multiple documents is that you may unintentionally end up creating many more pages of
documentation in aggregate than is necessary. It is important to understand that DAD is a
framework, to which you adapt the techniques that you find most effective. The key is to satisfy
the goal of the Inception phase, providing just enough written documentation to achieve
stakeholder concurrence on the vision and gaining agreement to start building the appropriate
solution. Table 12.7 shows alternative approaches that you may have taken in our situation.

Table 12.7. Alternatives to the Approach That We Took for Our Inception Phase
Concluding the Inception Phase

Mark, Louise, and Pete meet with Dean, the project sponsor, and Terry, the enterprise architect,
to have a one hour lightweight milestone review for the phase. Louise walks Dean through the
document.

Louise: Dean, we have spent a few days fleshing out the problems of continuing to use our
current store systems and how it is contributing to declining sales in our stores. We have outlined
a suggested solution for replacing the store systems in the vision statement that we have here.

Dean: Remind me again whats in this vision statement?

Louise: The vision statement summarizes the current business problem, the suggested solution,
the key features that will be delivered, the project timeline, key stakeholders, constraints, and
risks. It is like a brochure that explains what you will get for your investment.

Dean leafs through the document.

Dean: Wow, what is this, hand-drawn diagrams?! Mark, for an expensive consultant this is very
unprofessional! <frowns>

Mark: As an expensive consultant, I could have billed you an extra 4 hours to make these
diagrams look pretty, but I believe that they are readable as they are. On agile projects, we try to
eliminate unnecessary work to save you money. I would suggest that it would actually be
unprofessional of me to charge you for frivolous work of gold-plating documents, wouldnt you
agree?

Dean: I suppose you are right. Continue....

Louise: As you can see from the schedule section, we plan to deliver increments of your solution
for your review every two weeks.

Dean: Okay. Now I understand that based on your findings, you dont think that it is realistic
from a time and cost perspective to give this new application to all of our 250 stores?

Mark: Yes, that is correct. The budget doesnt allow us to upgrade all of the stores in the first
release. Additionally, rolling out the solution to all stores across Canada will take many months.
It will take time to configure and ship the hardware to all of the stores, and we have a limited
number of trainers to help the staff convert to the new system. So we are planning to install the
new system in 54 stores over a six-week period in Q3.

Dean: That makes sense to me. We will have more budget next year to roll out the system to the
remainder of the stores. We dont want to be changing systems in our busy holiday season.

At the end of the session, Mark asks for and receives approval from Dean to continue into the
next phase of the project (Construction) to start implementing the solution.

Dean: Well, congratulations! I would never have believed that you could put together such a
concise picture to frame the project and its business case.

Mark: Thanks. Finally, as you requested weve summarized how our time was spent throughout
the project (see Table 12.8 for the listing), and I think youll agree that we stayed focused on the
high value activities and didnt get down into the specification weeds. We achieved this by
structuring our time in a timeboxed manner and by capturing just the essentials at a high level.
This is how were going to proceed through the rest of the project.

Table 12.8. Summary of Tasks Completed and Work Products Produced in the Inception Phase
Concluding Thoughts

So there you have it. A successful ending for this projects Inception phase. Granted, on some
projects things do not always work out so smoothly. Sometimes upon completing Inception there
is not a clear indication that the project makes good financial sense. In this case the project may
be cancelled, or another iteration started to investigate alternatives, such as a changed business
process or buying a package. Although some organizations see cancelled projects as a sign of
failure, the truth is that cancelling hopeless projects should be considered a success if they are
cancelled before a substantial investment is made in them.
We stress strongly that this case study shows only one possible way of getting to the same result.
DAD is not a prescriptive methodology. Rather, it is a goal-driven framework from which you
can draw ideas to achieve these goals. In this case, we want to achieve stakeholder concurrence
that it makes sense to invest in a proposed solution to a given business problem.