Defining work items is a challenge. We could argue that a work item is anything that is delivered to the customer. As much as we've been trying and done some good work on defining user stories over the last decade it’s still a major source of confusion for a lot of projects. Let’s try another way using examples or scenarios.

1. Dimitar Bakardzhiev
Managing Partner
Taller Technologies Bulgaria
@dimiterbak
Project Scope preparation

2. Product Scope
• Product scope documents the features and functions
that characterize the new product that the project will
be undertaken to deliver.
• Usually the features and functions are called
requirements and are presented using vehicles such
as use cases and user stories.

3. Project Scope
• Project scope is the work that needs to be
accomplished to deliver a new product with specified
capabilities (features and functions).
• Project scope needs to be broken down into work
items to be used for planning purposes.
• Even for a quality related requirement such as “the
system should scale horizontally” we need to have a
work item.

4. If you have to report progress on a
work item it is too big – it is either
done or not done.

5. INVEST mnemonic
Independent: the work items can be delivered in any order
(loosely coupled and highly cohesive)
Negotiable: the details of what's in the work item are co-created
by the developers and customer during development.
Valuable: the functionality is seen as valuable by the customers
or users.
Estimable: the programmers can come up with a reasonable
estimate for building the work item
Small: work item should be delivered in a small amount of time.
What small means?
Testable: you should be able to write tests to verify work item
works correctly.

6. The most important parts are the “I”
and the “V” – we know that someone
wants to buy it and I can build it in any
order.

7. Defining work items is a challenge
In order not to have difficulties explaining the customers
what the product will look like we are communicating with
the customers using examples about how the new
product will function. That is interesting and valuable right
away.
Examples are of course smaller than user stories. We
need more of them in order to do the same thing we could
do with stories.

8. Thinking in examples or scenarios
• The important conversations and real collaboration
with the customers happen when we explore the
features and create the scenarios.
• “Can you give me an example?” is the most important
phrase that we as developers can use when dealing
with business people such as product owners,
business analysts or the people that actually run the
customer’s business.
• For every feature we’ll have a number of scenarios.
Not necessarily a small number either.

9. Steps to identify work items
1. Define product scope
2. Identify feature areas
3. Create scenarios
4. Identify user stories (work items)

10. Features
ScenariosUser stories

11. Scenario
• A scenario is a test customers could understand
written in their ordinary business language. It is an
acceptance test - formal test conducted to determine
whether or not the system satisfies its acceptance
criteria and to enable the customer to determine
whether or not to accept the system.
• We as developers have the tendency to focus on the
details, but scenarios should not talk about buttons,
lists, objects, queries etc.

12. Scenario format
Scenario #: Title
Given [context]
And [some more context]...
When [event]
Then [outcome]
And [another outcome]...

13. How to write a scenario?
• Use personas (Joe, Tom) not “The user” or “The
system”. Personas have names, backgrounds and
goals working with the system.

14. From features to scenarios
• For each feature there usually are one sometimes two
key or kernel examples that captures the important
ideas about (are the essence of) that feature.
• If we understand those key examples the rest is just
details, just variations, just developers being overly
paranoid or customers being overly ambitious.
• The goal is to identify the kernel scenarios that we
should build first. And then we can build the rest of
scenarios in any sequence. That maximizes our
flexibility to change the schedule when the constraints
change. It maximizes our capability to get high value
for low cost.

15. Kernel scenario
• If we build the kernel scenario all the rest of the
scenarios can be built independently.
• We might not get value from having just the kernel. We
might not get value even from the kernel and two other
scenario.
• But if we identify the kernel first, and they we identify
the other variations because the variations are
independent of each other it gives us the best chance
to be adaptable.

16. How to get to the kernel scenario?
1. Write any scenario in full detail. It doesn't have to be
the most interesting or the simplest or the most useful.
2. Contract. Take extra details out of the scenario by
asking the question “Can I remove that detail?”. The
point is to figure out what is the absolute minimum that
the user needs to tell the system to make it do it’s job.
That would be the kernel!
3. Expand. During this phase we look at the kernel
example from Contract phase and we say “That’s
bad”. We ask two questions “How could we make it
better?” and “What could go wrong?”. And each of
those will identify a new scenario which we’ll write
down.

17. User Story
• User stories are the centerpiece of the way we plan
and manage software projects.
• User stories aren't requirements – they are a way to
organise a collaboration on requirements.
• A user story is a token of conversation with the
customer.
• We should not write all details in the User Story but we
should retain it so that when you have a chance to talk
with the customer they will know what to talk about.
• We will use them as work items to track project
progress.

18. User Story format
Narrative:
As a [role]
I want [feature]
So that [benefit]

19. References
Product Sashimi - J.B. Rainsberger http://vimeo.com/37026071
Neil Killick http://neilkillick.com/2014/07/16/my-slicing-heuristic-concept-explained/
Dan North http://dannorth.net/whats-in-a-story/
Acceptance Test http://c2.com/cgi/wiki?AcceptanceTest
http://www.extremeprogramming.org/rules/functionaltests.html
System context diagram http://en.wikipedia.org/wiki/System_context_diagram
http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/1355/Introduction-to-
Context-Diagrams.aspx