Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Use-Case 2.0: the Power of Use Cases with the Lightness of User Stories

No description
by

Piermarco Burrafato

on 16 March 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Use-Case 2.0: the Power of Use Cases with the Lightness of User Stories

Prepare
Product Backlog Augment Specification Use Cases User Stories good for write a walk :¬) Use-Case 2.0 the best of 2 worlds The richness of the lightness of A technique gaining popularity
Paired with agile development... A very popular technique,
A hub to other disciplines... use cases + ...while keeping agility on the other hand Big picture on the one hand... user stories use cases are Iteration Backlog The Real Requirements and UX work starts Within each iteration, use-case slices are selected in order of priority from the Iteration Backlog. Selected slices get prepared, meaning that use-case narrative gets fleshed out on a Just-In-Time basis: only the flows that describe the story will be detailed out. At the same time, UX design is carried out and the test cases are created for the slice. More Requirements Techniques Analysis, Design, Implementation and Testing As a slice gets prepared (flows + test cases + UX design), development work can start which follows the usual pattern: analysis, design, implementation and testing. As part of the analysis, a use-case realization is produced by the System Analyst to identify how components of the systems as well as other systems collaborate with each other to realize the story. This activity is key since it adds up details to the previously identified gaps in the other areas of the Enterprise Architecture. Evaluating Results Testing means more than just making sure there are no defects - it also means making sure the solution meets expectations. Holding frequent demonstration and review of working software builds confidence in both the Business and the IT and allows fine tuning of direction: a recipe for keeping the project on track. Testing is essential for closing the loop - it is a means for evaluating whether the overall project objectives were achieved As development goes on, holding frequent demonstration and review of working software builds confidence in both the Business and the IT and allows fine tuning of direction: a recipe for keeping the project on track. Comparing the results delivered against the desired outcomes will tell us whether we have delivered the right thing. All we can do in this time box Communicate in a language that crosses specialties

Describe what the system will do by focusing on desired outcomes / user goals

Give a complete picture of the product's functional scope

Allow check for “completeness”

Suitable when workflow is a key aspect of the product

Give advance notice of items needing research

They are the test cases

They are the starting point for the design of effective user experiences

They 'drive' the development through design and code Business Opportunity Solution Deployment Use-Case 2.0 in action ` Understand the Problem Explore Solutions Envision Enact Prepare Evaluate Alternatives Plan the Time Box Dispatch to Queues Develop Evaluate Results Product Development Exploring Solutions at a High Level Time to brainstorm solutions that produce the desired outcomes use cases are sliced up Inital Product Backlog seeded with high value stories Putting Tasks into Development Queues Tasks needed to realize the use-case slice the goal of any requirements approach is drive effective discussions
about what the system should do to come to a shared understanding
of what is going to get built there are different techniques to capture requirements
each has pros and cons... let's review them visualization techniques use cases are complemented by benefits :¬) user stories pitfalls user stories User stories and backlog items don’t give the designers a context to work from focus on creating a visualization of the UI that implements some set of behavior storyboarding prototyping a storyboard is usually focused on just one path
through the behavior of interest while a use case captures all possible paths a storyboard tends to be more conceptual and still retains most of the flow information A prototype is especially useful for capturing look and feel requirements details that we want to keep out of the use-case narrative as they would render it unreadable. Storyboards can eventually evolve into a prototype With a prototype, it's harder to see the flow information some prototyping tools capture some of the flow information for simulation purposes

but this information is usually not a complete substitute for having a use-case description

most often the use case is useful as a kind of "script" for walking through a prototype great for small systems and small teams

they split nicely for short iterations

they provide features / line items

loved by development teams User stories and backlog items don’t give the project team much sense of “completeness” User stories and backlog items don’t provide a good-enough mechanism for looking ahead at the difficulty of upcoming work typical questions:

when is the user doing this?
what is the context of their operation?
what is their larger goal at this moment? Very often the development team bids/estimates the projects at (e.g.) 270 story points,
and then as soon as they start working, that number keeps increasing... Typical complaint: "We asked our customer (product owner) a question and they took 2 weeks to get us an answer.
We must have the wrong person in this role.” No, they don’t have the wrong person, they have a broken process – certain types of questions take
a long time to research, as the various departments and user groups work out what is the correct, balanced answer for the whole lot of them. vs use case a use case has a plot line
tells a story of someone using the system
to accomplish some goal -- i.e. it has more than one step

a use case describes the black box behavior of the system: it says what other systems the system under design talks to

a use case is the contents of multiple scenarios



a use case records decisions of a conversation user story a user story oddly is not a story at all, because it doesn't have a plot line -- it has no steps a user “story” (ahem again to the ‘story’ part of user story) is only the title of one scenario a user story doesn't good use cases are lightweight

stories

at user goal level

simple / easy to read

for all types of development

no GUI

no data formats

record of decisions made aren't heavy-weight for just green field application development functions complicated describing the GUI describing data formats at program-feature level tutorial on the domain a user story is a promise for a conversation. "About what?" one might ask... About the scenario for which this is the title use cases can be written all up front or just-in-time each to completion or in (usable) increments As someone said (used to be Einstein until the attribution has been debunked): “Make things as simple as possible, but no simpler.” Use cases, indeed, require a bit more work upfront than user stories or backlog items, but they bring value for that extra weight. In particular, use cases
do provide context... The developers are depressed and the sponsors are equally depressed by this. How big is this project, really? A very simple idea -

To get to the heart of what a system must do, you should focus on who, (or what) will use it,

And then look at what the system must do for
them to help them achieve something useful. ... allow check for "completeness"... ... Give advance notice of items needing research... Manage Your Energy From Product to Iteration Backlog All we can do in this time box Iteration Backlog Analyze a use-case slice Specify more requirements on an ad-hoc basis Not all the interesting things that a system has to do can be described by usage scenarios. For certain areas of the solution, other requirements techniques may be adopted to capture certain requirements. Not only testing there are no defects
the solution meets the desired outcomes Comparing the results delivered against the desired outcomes will tell us whether we have delivered the right thing First goal: Have all stakeholders agree on a common problem analysis The problem of:


Affects:

The impact of which is:


A successful solution would: Zeteo and MS Word integrated only one way (dossiers can be exported and edited in Word but not imported back in Zeteo) Our law firm clients (Lawyers and their Assistants) Lots of double work, frustration, low throughput of dossiers that ultimately results in our customer's clients dissatisfaction. Be to enhance the current Zeteo with text editing capabilities so that export to Word is no longer needed. Problem Position Statement The result of exploring solutions is Actor-Goal list Use-Case model overview Use-case catalog most risky use cases will require a bit more elaboration Bulleted outlined use-case Use-case storyboard A solution architecture is drafted meanwhile Solution architecture If this seems like a lot of work, keep in mind that everything is really just an
early working version at this point, just enough to drive ongoing discussion. Stakeholders "test drive" the alternative solutions and provide feedback in rapid, interactive explorations. Evaluating Alternatives Comparing solutions back to the desired outcomes helps to determine which best meet the needs of the business Work products of the Envision phase Vision document Use-case model Use-case narrative We favor communication over documentation and decision-making over sign-off. However given the very nature of global teams, it is important to have documentation to record decisions, allow on-going discussion, and for future reference. The following is a list Business Analysis artifacts. Mission To capture the right solution to the right problem
To communicate "what" and "why"
To provide a high-level context for more detailed requirements Benefits Communicates a strategy against which all future decisions can be validated

Communicates understanding of:
Problem space
Stakeholder types
Desired outcomes (expected business capabilities)
Business case
Envisioned product solution
Value proposition
Features Who All team members How By rallying team members behind an idea and give them the context for decision-making in the requirements area. Mission To provide an overview of the intended behavior of the system in terms of the actors it serves and the goals it supports
To capture the end-state big picture of the product's functional scope Benefits Provides a basis for agreement between stakeholders and the project team in regards to the intended functionality of the system

It guides various tasks in the SDLC Who All team members How By setting the boundaries around the scope of the solution

By providing a mile-wide, inch-deep description of the product's functionality Mission To capture all required flows of events to achieve a user goal Benefits Provides all stories about how an actor interacts with the system to achieve a particular goal Who All team members How By setting the context for user stories and backlog items. How do we conjugate the power of use-case modeling with the lightness of user stories? By just observing this A use case is the contents of many scenarios (stories) How much work upfront is required to slice up the use cases? A little - all we need to know is the structure of the use-case narrative ... and across releases... We don't need a fully described use case to start slicing use-case slices seed the product backlog up to this point use cases have remained lightweight this is
the essence of
Use-Case 2.0 Supporting Information Mission To capture important terms used to describe the system (glossary and domain model), and any requirements that don’t fit inside the use-case model (global requirements and quality attributes, industry standards for coding, presentation, language, safety) Benefits Provides a central location to look for terms and abbreviations that may be new
to the team and to find the global quality attributes that everyone in the team should understand Who All team members How By listing all terms, business rules, operational constraints, design constraints, standards, and system-wide requirements Primary Output Optional Vision document How about the patients (the stakeholders)?
What are their pain points?
How do they perceive the problem at stake?
What are the root causes of the problem?
What are, in other words, their desired outcomes for a solution?
What are the business capabilities they expect the solution to enable? Now that we know the problem... addresses all that Vision document Stakeholder Analysis What we know so far: problem stakeholders desired outcomes Use-case model Use-case narrative Vision document Solution Alternatives chosen solution pros & cons
risks
assumptions
dependencies one which is financially worth Vision document foundations for more elaborated requirements stakeholders The purpose of the Envision cycle is to establish a In order to build a compelling product we need to know the problem opportunity we intend to solve we are chasing Vision for the product under design problem space desired outcomes solution space to understand business case to provide adoption of the practice in a service-oriented enterprise Work products of the Prepare phase Vision document Use-case model Use-case narrative We favor communication over documentation and decision-making over sign-off. However given the very nature of global teams, it is important to have documentation to record decisions, allow on-going discussion, and for future reference. The following is a list Business Analysis artifacts. Supporting Information Primary Output Optional The purpose of the Prepare cycle is to prepare we need plan the project has a go seed the product backlog product backlog to seed the queues use-case slices to plan the next with just enough items
to start enacting our Vision just enough time box to assign tasks to the different dev just enough to seed the product backlog , , ... just enough slices are popped from the top and prepared Use case in essential outline state BF and A1 get fleshed out test cases are created
to adrees the tests
in the slice Test case use-case storyboard gets enhanced
to visualize the story in the slice Use-case storyboard Use-case narrative Product Backlog Slices might be rearranged
to fit the time box Iteration Backlog Use-case model more actors and use cases
may be found as result
of this activity Components cooperate to realize a story Domain model Business process model Decision model Requirements left out of a use case proper, which otherwise would make it cluttered and unreadable Supporting information Design Implementation Use-case realization Make sure Work products of the Enact phase Use-case narrative Supporting information Use-case realization* We favor communication over documentation and decision-making over sign-off. However given the very nature of global teams, it is important to have documentation to record decisions, allow on-going discussion, and for future reference. The following is a list Business Analysis artifacts. Use-case model Primary Output Optional Vision document iteration 0 pre-project inception solution assessment solution design iteration 1+ project in-flight backlog before each grooming iteration 1+ project in-flight elaboration construction & iterations Slicing the use case up into stories, allows us to keep the big picture of the product scope on one side... ... while organizing the delivery of the product in iterations... their stories have only been identified and their flows won't be fleshed out until needed on a just-in-time basis hold a use-case workshop to identify actors and their goals refined into Actor catalog The purpose of the Enact cycle is to deliver a valuable increment of the product by looking at the is now sliced and diced the big picture of the product scope we've seeded the product backlog use-case slice with just enough items
to start enacting our Vision time box for each in the iteration backlog and do analysis development testing Test case* (*) not a BA deliverable (*) not a BA deliverable * (*): by IJI http://www.ivarjacobson.com/
Full transcript