Sign up to save your podcasts
Or
Share MBA034: Use Case 2.0 – Interview with Ian Spence
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
MBA034: Use Case 2.0 – Interview with Ian Spence
In this episode, author Ian Spence introduces us to a different way to utilize Use Cases in agile environments – Use Cases 2.0.
Ian Spence specializes in large-scale agile adoptions and practice-based organizational change. He’s an experienced agile coach and has worked with hundreds of projects to introduce iterative and agile practices. He’s also the co-author of two influential software development books, “Use Case Modeling” and “Managing Iterative Software Development Projects”.
After listening to this episode, you will understand:
http://traffic.libsyn.com/masteringbusinessanalysis/MBA_034__Use_Cases_2.0_-_Interview_w.mp3
Show Notes
Why Use Cases?
The biggest advantage to using use cases is that it provides you with a way to create a visual model of the system as a whole. They give you a great way of understanding the boundary and entirety of a system in a way everyone can understand.
People often go wrong with use cases when they don’t understand the relationship between the use case diagram and the requirements or design of the system. People forget that software engineering is about the art of the possible and try to write these incredibly detailed requirements specifications that remove any ability of teams to innovate. Rather than focusing on the goals and the value, they get caught up in the design and create large, detailed specifications that don’t allow for fast feedback.
Done well, use cases are great for creating a shared understanding of the system as a whole which is invaluable as you start to plan, design, and build any kind of software system.
When you build a use case model, it’s to build understanding. Keep it simple.
The Birth of Use Case 2.0
Ian published an eBook to demonstrate a way to address using use cases in the iterative and incremental development environments of agile after seeing people struggle with use cases. The idea behind Use Case 2.0 came from Ivar Jacobson’s work on slicing use cases to support aspect-oriented software development and Ian Spence’s work on populating the backlog with use case slices. Use Cases 2.0 encourages people to develop use cases slice by slice with varying levels of detail. It encourages collaboration and emergent design.
Getting Started with Use Case 2.0
One of the principles of Use Case 2.0 is to start with and understand the big picture. Start by building a simple use case model, find your actors (which will help you understand your user types), and identify the goals that the system is going to support.
From there, you can think in terms of a minimum viable system and identify the use cases that will be most critical to achieving the goals. This may also allow you to eliminate some low value or low importance use cases.
“Over 60% of software code written is for error handling.”
Once you understand the big picture and critical use cases, focus on the “happy path” scenarios and create a use case based on that with just enough detail. Perhaps you can simply bullet out the happy path or if required for regulatory or other reasons, you can provide more detail.
Find the basic path and most obvious alternatives and create a slice through it. That could be one path or one test case through the scenario to give to developers to develop. Have a conversation with developers as to the requirements and test cases associated with that thin slice. This allows for emergent design.
As developers are working on the first few slices, analysts can be working on the next few slices of use cases.
How Do We Slice Use Cases?
When we slice use cases, we look at them in terms of a series of steps for a basic flow without all of the variants. Look at the basic flow for certain types of customers or products to reduce the potential variants. Afterwards, you can look at which alternatives or other ways of achieving the goal are important and create slices for those.
Slice around flows and scenarios, around the data, risk, size, and value. Don’t try to find all alternatives up front. Just start with one and iterate from there.
Creating thin, vertical slices allows you to get feedback and adapt based on that feedback. Keep it lightweight at first and then fill in to the minimum level of detail needed.
YOUR HOMEWORK (Ian’s Tip)
What’s Your Take?
Do you use Use Cases in an agile environment? Do you have any advice to share? Please share your experience in the comments below.
Links mentioned in this episode
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
The post MBA034: Use Case 2.0 – Interview with Ian Spence appeared first on Mastering Business Analysis.
View all episodes
By Dave Saboe, CBAP, PMP, CSM | Certified Business Analysis Professional | Agile Coach
4.7
8282 ratings
In this episode, author Ian Spence introduces us to a different way to utilize Use Cases in agile environments – Use Cases 2.0.
Ian Spence specializes in large-scale agile adoptions and practice-based organizational change. He’s an experienced agile coach and has worked with hundreds of projects to introduce iterative and agile practices. He’s also the co-author of two influential software development books, “Use Case Modeling” and “Managing Iterative Software Development Projects”.
After listening to this episode, you will understand:
http://traffic.libsyn.com/masteringbusinessanalysis/MBA_034__Use_Cases_2.0_-_Interview_w.mp3
Show Notes
Why Use Cases?
The biggest advantage to using use cases is that it provides you with a way to create a visual model of the system as a whole. They give you a great way of understanding the boundary and entirety of a system in a way everyone can understand.
People often go wrong with use cases when they don’t understand the relationship between the use case diagram and the requirements or design of the system. People forget that software engineering is about the art of the possible and try to write these incredibly detailed requirements specifications that remove any ability of teams to innovate. Rather than focusing on the goals and the value, they get caught up in the design and create large, detailed specifications that don’t allow for fast feedback.
Done well, use cases are great for creating a shared understanding of the system as a whole which is invaluable as you start to plan, design, and build any kind of software system.
When you build a use case model, it’s to build understanding. Keep it simple.
The Birth of Use Case 2.0
Ian published an eBook to demonstrate a way to address using use cases in the iterative and incremental development environments of agile after seeing people struggle with use cases. The idea behind Use Case 2.0 came from Ivar Jacobson’s work on slicing use cases to support aspect-oriented software development and Ian Spence’s work on populating the backlog with use case slices. Use Cases 2.0 encourages people to develop use cases slice by slice with varying levels of detail. It encourages collaboration and emergent design.
Getting Started with Use Case 2.0
One of the principles of Use Case 2.0 is to start with and understand the big picture. Start by building a simple use case model, find your actors (which will help you understand your user types), and identify the goals that the system is going to support.
From there, you can think in terms of a minimum viable system and identify the use cases that will be most critical to achieving the goals. This may also allow you to eliminate some low value or low importance use cases.
“Over 60% of software code written is for error handling.”
Once you understand the big picture and critical use cases, focus on the “happy path” scenarios and create a use case based on that with just enough detail. Perhaps you can simply bullet out the happy path or if required for regulatory or other reasons, you can provide more detail.
Find the basic path and most obvious alternatives and create a slice through it. That could be one path or one test case through the scenario to give to developers to develop. Have a conversation with developers as to the requirements and test cases associated with that thin slice. This allows for emergent design.
As developers are working on the first few slices, analysts can be working on the next few slices of use cases.
How Do We Slice Use Cases?
When we slice use cases, we look at them in terms of a series of steps for a basic flow without all of the variants. Look at the basic flow for certain types of customers or products to reduce the potential variants. Afterwards, you can look at which alternatives or other ways of achieving the goal are important and create slices for those.
Slice around flows and scenarios, around the data, risk, size, and value. Don’t try to find all alternatives up front. Just start with one and iterate from there.
Creating thin, vertical slices allows you to get feedback and adapt based on that feedback. Keep it lightweight at first and then fill in to the minimum level of detail needed.
YOUR HOMEWORK (Ian’s Tip)
What’s Your Take?
Do you use Use Cases in an agile environment? Do you have any advice to share? Please share your experience in the comments below.
Links mentioned in this episode
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
The post MBA034: Use Case 2.0 – Interview with Ian Spence appeared first on Mastering Business Analysis.
More shows like Mastering Business Analysis
View all
Freakonomics Radio
32,246 Listeners
The Ben Shapiro Show
153,989 Listeners
The Economics of Everyday Things
1,643 Listeners
Business Analysis Simplified
0 Listeners