User stories, estimates, planning, design - Lean development and Agile methodologies lesson 4

User Stories, Estimates, Planning, Design

May 6, 2016

User Stories Estimates Planning Design Wrap up References

User Stories

Estimates

Planning

Design

Wrap up

References



Problems:

User stories helps us to solve problems

I Communication problem

I Power Balance

I Resource allocation

I Imperfect schedule



Problems:

Communication problem

I Those who want the software need to communicate to theones that build the software



Problems:

Balance

I Balance between business side and development

I If business is dominantI "I need this by this date"I Functionality and date are mandatory

I no matter if feasibleI no matter if requirements are clear

I If development is dominantI Techinical language used instead of businessI Trap: the business should not be forced to talk technical

language... we force business to talk technology language



Problems:

Resource allocation

I Should be a shared problem

I Business wants more than feasible

I how resources should be allocated should be a problem of bothsides



Problems:

Scarce resource done wrong:

I If developers are required to address the scarcity of resourcesI May trade quality for additional featuresI May only partially implement a featureI May solely make decisions that should involve the business

I If the business is required to address the scarcity of resourcesI Lengthy upfront requirements negotiation and signo�I Features are progressively dropped as the deadline nearsI note: the ugly documents are there because developers are not

happy about changing requirements!



Problems:

Imperfect schedule

I We cannot perfectly predict a software scheduleI As users see the software, they come up with new ideasI Too many intangiblesI Developers have a notoriously hard time estimating

I If we can't perfectly predict a schedule, we can't perfectly saywhat will be delivered



Approach

What do we do?

I We make decisions based on the information we haveI but OFTEN!

I we spread decisionmaking across the projectI rather than making all the decisions at the beginning

I we take into account changes in requirement during the entiredevelopment process

I User Stories can help us



What are User Stories?

Structure of a user story

I "As a <user role>, I <want/need/can/etc> <something> sothat <bene�t>."

I As a CONTENT OWNER I want to MAKE A PICTUREAVAILABLE ON THE INTERNET so that I CAN EASILYSHOW IT TO FRIENDS

I As a FRIEND I want A NOTIFICATION WHEN A NEWPICTURE IS AVAILABLE so that I KNOW WHEN THERE ISNEW CONTENT TO SEE




What does this bring?

I provides a functionality from a user perspective

I stress where is the value

I identi�es explicitly the goal of the user

I is expressed in the domain language, so everybody canunderstand it

I express goals that are not always software requirements




More on So That

I As a visitor I want not to sign-in or sign-up so that...




More on So That

I As a visitor I want not to sign-in or sign-up so that...I ...I can access the functionalities immediatlyI ...I give no personal data to the website

way of splitting the US and implementation can changeradically depending on what the goal is

sometimes the so that part is the most important one, and theUS can change completely once the goal is clear




Three Cs

I CardI Traditionally, written on small cardsI Cards may be annotated with estimates, notes, etc.

I ConversationI Details behind the story come out during conversations with

product ownerI The promise of the conversation allows the PO not to write

the requirementsI The US points to the requirements, somehow.

I Con�rmationI The Acceptance criterion.




USs are short

I Conversation can help to understand what to do..I On the back you can add the description of what is expectedI This are somehow the things that should work... condition of

satisfaction, done criteriaI (can be translated to tests to perform to accept the story)I Think of them as the script of the demo card

I Another way to add detailsI Write smaller stories




Digital tools for handling USs across distributed teams




US in backlog

I Bottom: large USs, vague (very largeUSs are called Epics)

I USs are split into smaller USs whiletheir priority grows




A user story is

I a placeholderI to remind the team and PO to talk

I value for user

I mutable in time




A user story is not

I a requirement

I detailed

I immutable




I.N.V.E.S.T.

I IndependentI Self contained, no inherent dependency

I NegotiableI Subject to changes until they are scheduled

I ValuableI Must be valueable for the user

I EstimableI Ready to be estimated

I ScalableI Small enough to be estimated/prioritized

I TestableI Enough information to be tested



Why User Stories?

Advantages of User Stories

I Shift focus from writing to talkingI If requirements are written down, the user is getting, at best,

what's written

I Easier to understand and to remember

I Encourage iterative development and evolution

I Have the right size for planning (if not, split them!)

I Help both development and planning

I Encourage partecipatory design and goal oriented design

I Focus on the user goal, not on the attributes of the system



Why User Stories?

Do you remember?

I Tha Agile Manifesto: ValuesI Individuals and iteractions over Processess and toolsI Working software over Comprehensive documentationI Customer collaboration over Contract negotiationI Responding to change over Follwing a plan

I User stories lean toward the left side, traditional requirementslean toward the right side



Recap

Recap - User Stories

I As a <role> I <something> so that <bene�t>

I Card, Conversation, Con�rmation

I USs are placeholders

I USs express a value for the user

I USs start big and vague, they become smaller and a bit moredetailed when their priority gets higher

I Independent, Negotiable, Valuable, Estimable, Scalable,Testable



Introduction

Make groups of 3-4 people and take 5 minutes to estimate...

I how long does it takes to drive from here to Prague?

I how long does it takes to read all the Game Of Thrones /Harry Potter / Twilight saga?



Introduction

What was your approach?



Introduction

Estimate size, derive duration

I Size -> Calculation -> Duration

I two steps!

I Once you estimate the size, you can try to do a bit of it, thenestimate the duration



Introduction

User stories use

I Story Points

I Ideal Days



Story Points

Story Points

I Story Points are a RELATIVE measure of size

I How long a user story will take (e�ort)

I In�uenced by complexity, uncertainty, risk, volume of work, etc.

I Relative values are what is important:I A login screen is a 2.I A search feature is an 8.I Not how much time it will take!

I Basic math properties should holdI 5+5 = 10

I It's independent on the skill sets of who's working on that



Story Points

Try estimating the following animals size in points

I Lion

I Kangaroo

I Rhinoceros

I Bear

I Gira�e

I Gorilla

I Hippopotamus

I Tiger



Story Points

Estimating with story points

I Becomes easier: there's something similar already there

I Separates completely estimation of e�ort from estimation ofduration

I Story points are additive; time-based estimates may not be (ifwe mix Bob time and Anne time)



Ideal Days

Ideal time

I How long something will take ifI no one interrupts youI it's all you work onI everything you need is available



Ideal Days

Ideal vs Elapsed

I IdeallyI Monday has 8 hoursI Each week has 40 hours

I InsteadI Each day has something likeI 2 hours of meetingsI 2 hours of emailI 4 hours left for the project

I How long it will take to...?I Are you asking ideal time or elapsed?



Story points or ideal days?

Advantages of story points

I story points help drive cross-functional behavior

I story point estimates do not decay

I story points are a pure measure of size

I estimating in story points is typically faster

I my ideal days are not your ideal days




Advantages of ideal days

I ideal days are easier to explain outside the team

I ideal days are easier to estimate at �rst

I ideal days make velocity predictions easier




Story Points or Ideal Days?

I Majority of teams prefer using Story pointsI including myself :)

I Ideal days are ok, too, as long as you don't mess with idealdays and real days!



Planning Poker

Planning Poker is an iterative approach to estimating

I we want the team to converge to an estimate

I not all numbers are vaildI the distance usually grows, as we just want a rough estimateI e.g.

I 0 121 2 3 5 8 13 20 40 100 ...

I 1 2 3 5 8 16 32 ...I 1 2 3 5 8 13 21 34 ...

I in this way there is no discussion about a US being a 18 or 19:it's larger than 13, so we pick 20



Planning Poker

Planning Poker Steps

I Each estimator is given a deck of cards, each card has a validestimate written on it

I Customer/Product owner reads a story and it's discussedbrie�y

I Each estimator selects a card that is his or her estimate

I Cards are turned at the same time

I Discuss di�erences (especially outliers)

I Re-estimate until estimates converge



Recap

Recap - Estimates

I Estimate size, derive duration

I Story Points are a relative measure of size

I Ideal days exists, too. But we like story points more

I Planning poker helps team to faster and better estimate USs



Introduction

Planning is...

I importantI Plans guide our investment decisions

I helpfulI for allocating resourcesI to understand if the project is on track

I but...I planning is di�cult, and plans are often wrong



Introduction

Common reactions

I no planning at all

I so much e�ort that teams are sure their plan can't be wrong



Introduction

Cone of uncertaintiy



Introduction

Why planning?

I reducing (and/or identifying) risk

I reducing uncertainity

I support better decision makingI make sure we're working on the most valuable projectI make sure we get the best possible tradeo�

I establishing trustI reliable plans enable reliable deliveries

I convey informationI a plan provide a set of baseline expectationI usually with information attached (assumption, approach etc)

Prediction is very di�cult, especially about the future.



Introduction

Good plan

I a good plan is one that stakeholders �nd su�ciently reliablethat they can use it as the basis for making decisions



Introduction

Planning VS Plan

I "Planning is everything. Plans are nothing"

I "No plan survives contact with the enemy"

Field Marshal Helmuth Graf von Moltke

I We want to focus on the ongoing (re-)planning activity, not onthe current plan

I The knowledge and insight gained from planning persists aftera plan is replaced by another one



Traditiona Planning Issues

Traditional Planning Issues

I Planning by Activity instead of Planning by Feature

I Features are not developed by priority, but to optimize

I We ignore uncertainity




Planning by Activity instead of Planning by Feature

I Traditional processes measure the progress by activity

I IssuesI Activity never �nish early

I "Work expands so as to �ll the time available for itscompletion"(Parkinson's Law)

I Lateness propagatesI Activities are not independent

I (if you estimated something wrong, estimates of similar itemsis probably wrong as well)

I We should remember the agile principlesI "Working software is the principal measure of progress"




Features are not developed by priority, but to optimize

I if all work will be completed, project customers have nopreference about the sequence in which that work is done

I but when the end of the project approaching, and there is notenough time, we often have to meet the schedule by droppingfeatures

I and since the features were developed not following priority,some important features may be dropped




We ignore uncertainity

I We assume that the requirement and analysis have removed alldoubts

I We assume users will not change their minds

I We assume during work nothing changes in how we want tobuild the solution



Ongoing Planning and RePlanning

We need a process that allows ongoing planning




Planning at release level




Planning at iteration level




How story points can help planning and replanning

I Velocity: a measure of a team?s rate of progress per iteration.I At the end of each iteration, a team can look at the stories

they have completed and calculate their velocity by summingthe story-point estimates for each completed story.

I The duration of a project is not estimated as much as it isderived by taking the total number of story points and dividingit by the velocity of the team



Recap

Recap - Planning

I Planning is important

I Plans often does not work

I Planning done wrong can be improved with agile approaches

I Replanning is something we should embrace



Introduction

Focus on the user

I If we design and develop digital products so that people usingthem can achive their goal, they will be happy and our productwill be a success



Introduction

The truth: poor product behavior

I Digital products are rudeI "Error! Unable to contact the server"

I Digital products require people to think like computersI "Save as..."I "Bu�ering"

I Digital products have sloppy habitsI Dangerous commands, no autosave...

I ...



Introduction

Why so much software is still frustrating?

I Because we focus on Planning and Development... and notenough on Design



What is Design

Design Activities

I Understanding the desires, needs, motivations, and contexts ofpeople using products

I Understanding business, technical, and domain opportunities,requirements, and constraints

I Using this knowledge as a foundation for plans to createproducts whose form, content, and behavior are useful, usable,and desirable, as well as economically viable and technicallyfeasible



What is Design

What this is about?

I If done correctly, design can provide the missing humanconnection in technological products



Digital product issues

Why digital product fails?

I Misplaced priorities

I Ignorance about real users

I Con�icts of interest

I Lack of a design process



Digital product issues - Misplaced Priorities

Traditionally, two forces provide inputs for the product

I Business

I Developers




Business

I Good at Identifying business opportunity

I Good at introducing the product in the market

I Provide just requirementsI often this is about chasing competition and what users say

they buyI little to do with what a user needs or desires




Developers

I Di�erent imperatives than the end user

I They are �ghting with technical problems, deadlines,incomplete, myopic, confusing and contradictory instruction.

I Often have no time or enough knowledge of how the productwill be used... still they have to buil it




Result of this two forces combined

I Reactive to market trends

I Reactive to technical constraints

I No one thinks about the user goals,needs of motivation

I Lacking of coherent user experience,and humanity




Ignorance about real users

I We knowI market segmentI incomeI what they do in the weekendI what they buyI ...

I We do not knowI how will they use the productI what pushes them to use the productI why they prefer our product or the competitor'sI how to push them to use our productI ...




Lack of a design process

I Technical feasibility is studied and considered

I Commercial feasibility is studied and considered

I What about desirability? Design process is often missing



Success

Evolution of sw development cycle



Success

Success



Goal Oriented Design


I Understending the user's goals, need, motivation

I We try to identify the personal goals, not the short termobjective or the task

I Goals are motivations for the user and should describe whatthey are trying to achieve

I Tasks are the steps involved to help them achieve the goal.




Example of goals

I Experience goalsI Feel smart and in controlI Have funI Remain focused

I End goalsI Stay connected with friendsI Find music I loveI Get the best deal

I Life goalsI Be respected by my peersI Be an expert in...




Example

I Context: a company that sells houses. What is a possiblecustomer goal?

I goal: make sure my family is safe and happyI not a goal: �nd a house quickly and e�ciently in a given area




Thinking by user goals helps reshaping the UX, high level

capabilities, design and brand strategy

I e.g. instead of searching a new house by number of rooms, itmay be interesting searching by family composition



Personas

How can we identify the user goals?

I Research

I Qualitative research in this areas usually works betterI We are not trying to have objective resultsI We are not try to answer "how" "how much", but more

complex questions



Personas

Qualitative and quantitative research contributions

I quantitative research still providesinputs



Personas

Flow of the Goal Directed Design



Personas

How do we use all this information?

I We create models of users.

I This models are called Personas



Personas

Personas

I Simple but powerful concept

I We do not discuss how the personasare identi�ed... but it's fun



Personas

At the end you have something like



Personas

Do not try to design for every user



Personas

Try to design for speci�c user with speci�c needs



Personas

Strenghts of personas

I Communication between stakeholders, developers, designersI common language

I With common language it's easier to get common consesusand committment

I Contribute to multipe areasI product developmentI marketingI salesI support

I Help to avoidI elastic userI self referential designI corner case



Wrap up

Course Wrap up

I Development is about �nding technical solutions. But hassome uncertainty and requires creativity.

I Everything changes very often, and we're working on complexdomains, so lanning and making predictions is very di�cult

I Being able to react and adapt is important at every level, frommanagement to single teams

I Since everybody needs to react, teams and people must betrusted, and empowered, otherwise things will go bad



Wrap up

Two main themes across the entire course

I human beingI hiring good peopleI user storiesI conversationI user goalsI personas

I reaction to changeI leanI agileI planning and replanning

play it by ear!



Bibliography

Bibliography

I Agile Estimating and Planning, Mike Cohn, Chapters 1-4

I About Face, The essential of interaction design, 4th edition -Cooper, Reimann, Cronin, Noessel - chap 1, 2 - concepts fromchapter 3



Attribution

Attribution

I Dolby personas (C) bolt, fromhttp://boltpeters.com/clients/dolby/


Small Business & Entrepreneurship

User stories, estimates, planning, design - Lean development and Agile methodologies lesson 4