Agile Software Development
Epics, Stories, and the Definition of Done
Christopher Jones Fall, 2020-2021
School of Computing, DePaul University
Jobs, User Roles, and Personas
“Most companies segment their markets by customer demographics or product characteristics and differentiate their offerings by adding features and functions. But the consumer has a different view of the marketplace. He simply has a job to be done and is seeking to ‘hire’ the best product or service to do it.” [1]
Job
The fundamental problem that a customer needs to resolve in a given situation.
1/38
A fast food restaurant wanted to improve sales of its milkshakes.
• Traditional marketing segmentation techniques were employed. • No impact on sales.
2/38
A researcher spent a day in a restaurant capturing:
• When the milkshake was bought.
• What else they purchased with the milkshake. • Whether they were alone or in groups.
• Eat in or take out.
The results were interesting:
• 40% purchased in the morning. • Nothing else was purchased.
• Almost always alone.
• Take out.
3/38
The researchers then interviewed these customers:
• Most wanted something to make the commute more interesting and keep their free hand busy.
• They weren’t hungry yet, but wanted something that would help them make it to lunch time.
All of these customers had the same constraints:
• They were in a hurry.
• They were wearing work clothes. • They had, at most, one free hand.
4/38
They found that the milkshake performed its “job” better its competitors:
• Bagels were dry. If you add cream cheese or jam you end up with a mess.
• Donuts didn’t satisfy until lunch.
• Bananas were consumed too quickly.
In contrast the milkshake:
• Lasted about 20 minutes.
• Kept hands, clothes and vehicle clean. • Satisfied consumers until lunch.
It didn’t matter that it wasn’t healthful; that wasn’t its job.
5/38
Based on these findings, it became easier to determine how to change their milkshake:
• Make the shake thicker.
• Add fruit for more interest.
• Moved the milkshake dispenser to the front of the counter.
• Sell pre-paid swipe cards to allow customers to check out fast.
6/38
How do we identify jobs?
• Observation.
• Interviews.
• Compensating behaviors. • Coevolution.
7/38
Observation is a relatively passive approach to finding jobs. Its always possible that the interpretation of the observed behavior will be incorrect.
8/38
Interviews are a common way to finding jobs. However, the questions need to be carefully worded to avoid biasing the interviewee.
9/38
Compensating Behavior
A behavior performed to compensate for the deficiencies in, or results of, another behavior.
For example, P&G observed that dustpans were a compensating behavior since traditional mops and brooms didn’t clean up the dirt well. Resulted in Swiffer.
10/38
Coevolution
A process where research and development happen concurrently; the two feed off of one another.
For example, On-Star. What features would customers want? Answer: Get it out there and get actual data on why they sign up for the service and when they actually use it.
11/38
User Role
A collection of concerns and behaviors of a particular kind of user. It will have capabilities within an application.
Most software will be used by multiple kinds of users each acting in one or more roles to perform one or more jobs.
12/38
Brainstorm
Organize Consolidate Refine
Identify all roles that might interact with the application. Each participant writes down as many roles as they can think of, one per card.
Place the roles relative to one another. If there is any overlap between the roles, overlap the cards. Eliminate duplicates by unifying roles that are similar enough to be combined.
Add attributes like domain expertise, computer expertise, frequency of use, etc.
13/38
Sometimes it is helpful to define an actual “person” for a role. We can define this “person” in terms of the attributes that matter the most to our product (e.g. education, job, income level, hobbies, etc.)
Persona
A fictitious character who is a typical example of someone who plays one or more user roles.
14/38
Themes, Epics, and User Stories
15/38
Most agile approaches emphasize user stories as the primary means of capturing requirements.
User stories are much less formal than traditional requirements.
16/38
“User stories are a reminder to have a conversation with your stakeholder.” [2]
Scott Ambler
17/38
User Story
A very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.
A user story should capture the following major elements [3]:
• A written description of the story including the role(s) that participate in the story.
• Conversations about the story that help capture the details. • Acceptance tests that are used to verify that a story is done.
The business team or product owner is usually responsible for writing the user stories.
18/38
We often think of user stories as the functional requirements of a system, but they can also illustrate:
• Technical constraints.
• Non-functional requirements.
• Non-product work (e.g. presentations, operational work, etc.)
These are often written by the development team. Sometimes they go through a formal prioritization, sometimes not.
19/38
User stories are typically captured on physical or electronic cards:
• Physical cards, like index cards or sticky notes, are the most inclusive but are limited when it comes to geographically distributed teams.
• Electronic cards can be powerful, especially when combined with issue tracking or release management software.
Question: how do we write good user stories? Answer: INVEST!
20/38
Good user stories are [4]: • Independent
• Negotiable
• Valuable
• Estimatable • Small
• Testable
21/38
Independent
Avoid making one story dependent on another; it leads to prioritization and planning problems.
This can sometimes be addressed by combining the stories. Splitting the stories a different way might also remove the dependency. E.g., instead of splitting stories along functional lines (e.g. CRUD), perhaps they can be split based on the data being managed (e.g. user data, financial data, etc.).
This is always a problem when dealing with stories that involve multiple independent teams.
Cohesiveness describes how one story relates to another. E.g. a zoom-in feature might be very important, so we also do the zoom-out feature even if it’s of lesser importance.
22/38
Negotiable
Stories are not intended to be contractual documents. They are intended to allow the business and the development team to have a conversation about needed functionality when it gets close to the time that the functionality will actually be delivered.
Too many details when the story is first defined can make it seem as though everything has properly defined, even when it hasn’t been.
Timing is always a problem. Even if all of the specifics were decided when the story was first written, those specifics might have changed by the time the story is ready to be implemented.
23/38
Valuable
Each story should deliver value to either the user or the purchaser.
Users are concerned with what the software does. Purchasers are concerned with how the software does it does and perhaps even how it was developed.
Avoid stories that are only valuable to developers. For example, which sounds better to a business person:
• All database interactions use a connection pool.
• A standard license supports up to 50 concurrent users.
Certain government contracts might require that the software by developed in accordance with CMMI or ISO 9001. No obvious value to users, but valuable to purchasers.
24/38
Estimatable
Developers must be able to estimate a story.
Common reasons that a story cannot be estimated include:
• The developers don’t understand the business domain. Talk to the business users.
• The developers don’t understand the technical domain. Invest time in a proof-of-concept or spike.
• The story is too big. Split the story into smaller, estimatable stories.
25/38
Spike
A story that is focused on answering questions. It’s purpose is to turn unknowns and assumptions into knowns and certainties.
Timebox the research. The goal is to narrow the cone of uncertainty so that estimates on the implementation are feasible.
26/38
Small
Stories need to be appropriately sized for the team. The goal is to for them to be large enough to be meaningful but small enough to be estimatable and useful in planning. Beware of stories that are:
• Compound. Split into smaller stories.
• Complex. Split into research and implementation.
27/38
Testable
If a story isn’t testable, then it might as well not exist; there’s no way to determine when it’s been completed or when it’s correct.
Acceptance tests are a standard part of every story. Automation is always the goal.
28/38
Some stories are too complex to be completed within a single iteration.
We call such stories epics.
Epics need to be decomposed into smaller stories that can fit into a single iteration.
29/38
Stories can be decomposed into tasks.
Each task should be completed in much less than the total iteration
time.
Splitting a story into tasks allows multiple people to work on different pieces of the same story concurrently.
30/38
Epics, stories, and tasks are the major units of release planning and management. It can sometimes be hard to tell which one is appropriate.
• Epic. An epic cannot be completed in a single iteration. Epics must be decomposed into stories.
• Story. A story can be completed in a single iteration and represents a deployable piece of functionality and business value. Stories are often subdivided into tasks.
• Task. A task can be completed in a day or two. A task by itself provides little value; it’s there to help organize the completion of a story.
31/38
Focus on the goals that the various user roles are trying to accomplish when they use the product. These become the basis for the stories.
32/38
When a story is delivered, it is expected to provide actual, measurable business value. A smaller story that delivers some, reduced value, is preferable to delivering no value at all.
• Splitting a story along technical lines, makes delivering value in an iteration impossible. While this can’t always be avoided, a better approach is to split stories along functional lines.
• Remember, a story should be completed within a single iteration or it’s too big.
33/38
Defer UI concerns for as long as possible. Stories are about business value, not about design.
• Eventually UI details may emerge in the story, but you can usually keep them out completely.
34/38
Definition of Done
An old adage: Features are 90% done 90% of the time.
Definition of Done
A prepared list of all activities that must be completed before a story will be declared as “done.”
Not having a good definition of done makes it hard to complete stories in a single sprint.
35/38
Sample Definition of Done
1. Releaseable.
36/38
Sample Definition of Done
1. Unit/integration tested.
2. Ready for acceptance testing.
3. Deployed on demo server.
4. Code merged to master branch. 5. Code has an approved PR.
6. Code builds successfully.
7. No increased technical debt.
37/38
References i
[1] Clayton M. Christensen, Scott D. Anthony, Gerald N. Berstell, and Denise Nitterhouse.
Finding the right job for your product.
MIT Sloan Management Review, 48(3):2–11, 2007.
[2] Scott Ambler.
http://www.agilemodeling.com/artifacts/userStory.htm, 2009.
[3] Mike Cohn.
User Stories Applied. Addison Wesley, 2004.
[4] William C. Wake.
Invest in good stories, and smart tasks.
http://www.xp123.com, August 2003.
38/38