What is a Use case?

Use case is a list of actions or event steps that are typically defining the interactions between a system and a role to achieve a goal. Actor can be a human or an external system.

Why do we use "Use cases"?

The purpose of a use case is to describe system or user steps of a process. Use cases mainly consist of a Title, Description, Basic Flow, Alternate Flow,Pre-conditions,Negative flows,and post –conditions.Process flows would be used to visualize the use case steps.

How are use cases used in Agile-Scrum process?

• Use cases would help to discover the beginning and end of the process and various scenarios which may occur in that process.
• Then, a process would be created using the use case in order to visually represent the steps and flow.
• High level process flows would be created to describe the overall process.
• Detailed flows are created to show detailed steps, alternate flows, and negative flows.
• High level process flows would be used to write high level user stories.
• The Epics, Use cases and Process flows would be given to the team to break down the Epics into user stories which would fit into a sprint.
• A User story would comprise of several detailed steps depending on sizing.
• User story could be an alternate flow or a negative flow.
• On Agile projects, Process flows, and use cases would be used to derive Epics and User stories.

Scrum is a Management framework which is used to help cross functional teams to collaborate in order to develop a new releasable increment of value on a regular basis. Use cases and scrum should be ideal practices which would together enable teams to -

• Prioritize and identify values which are developed independently and tested.
• Collaborate to develop the releasable product increments to realize this value gradually.

These two practices are extremely effective and powerful when they are used together.

Avoiding Anti-Patterns

Usage of the use cases with scrum would help the team to avoid some common scrum anti-patterns which would include:

• There will not be any objective and clear basis for prioritizing the product backlog items.
• Lot of effort would be put into solution aspects that deliver a low and non–independent value.
• Critical requirements are discovered late and missed.
• A software that is working would be created and demonstrated in every single sprint. But nothing would result which can be released as it does not support any cohesive "end-to-end" usage to realize the end user values and goals.

How to start identifying good candidate product backlog items?

In order to identify small increments of value, the use case should be sliced horizontally. Each such "use case slice" would depict an end-to-end interaction with the service that delivers a real end user value as it enables a known subset of user population in order to achieve their goal of applying for a loan.

When used in scrum, each of these use case slices would be placed in a product backlog as a candidate product backlog item.

How to avoid bad product backlog items?

When an agile team doesn't use a "use-case slice" strategy to support agile delivery approach, the anti-pattern which would often result in that product backlog items would be created by "dicing" the application "vertically" into a set of "baby steps towards value".

This feels easy and natural for everyone because:

• Product owners would write user stories easily for these baby steps towards values.
• UI designers would know how to design the screen maps for every step to be taken.
• Developers and testers would independently develop and test these small use-case steps.

Everyone is happy except two types of people who would be unhappy -

• The users - who get nothing of value which they can actually use until right end of the endeavour, when all the use case steps have been developed and tested.
• The funders - who would be getting the worst possible "return-on-investment" deal big up front risk and investment with no return whatsoever till the end of the project.

As "dicing" the usecase in this way would be breaking the golden rule "at the heart of scrum" that each sprint produces something which is releasable. This would matter because the key bottom line benefit of an agile delivery approach. Which would be an economic game changer of resulting value back into the organization incrementally, by increasing profitability and decreasing the risk and exposure.

Use case Test Driven Development

In order to achieve a new value in each and every sprint, we need to stay focused on building what exactly is needed to add new value to the product which is not less, not more. There is an important technique to achieve focus which is known as "Acceptance Test Driven Development".

Use case 2.0 supports ATDD naturally through the identification of use case which would help to define, drive and test the correct end-to-end execution of a use case slice.

Each use case tast case is something which one can -

• Agree with the product owner.
• Script and Automate.
• Code until the test is passing.

Test cases would help to identify even thinner use case slices-each individual test case that is potentially being a use case slicein it's won right that could independently code,test, prepare for release and even potentially release.

Collaborative Design and Planning

Sprint plan would be constructed by the Agile teams by drawing out the solution design in the sprint planning meeting,including the component collaborations that are needed to realize each backlog item .

The resulting design sketch is known as "Use-case realization".

Each new component that is identified would depict something that the team would need to build and test which can be estimated and planned for the sprint which becomes a development task on the sprint backlog.