gathering requirements
© Finding hotes in ctarity
ReFing your see stories ways Keeping the ⁄ Eerie ot = © Glew: Casomer-focused User Sie mm Choose seating ion A ser willbe able to aisle or window seating
© Play planning poker
Trang 2Who a m
‘Abunch of techniques for working with requirements, in full S Ip
costume, are playing a party game, "Who am I?" They'll give you ol; u tỉ on
I'S
a clue and then you try to quess who they are based on what they say Assume they always tell the truth about themselves Fill inthe blanks next to each statement with the name (or names) of each attendee thatthe statement is true for Attendees may be Used in more than one answer Tonight's attendees: Blueskying - Role playing ~ Observation Planning poker You can dress me up as a use case for a User Story formal occasion Se ° ‘The more of me there are, the clearer things become
| help you capture EVERYTHING,
| help you get more from the customer
In court, 'd be admissible as firsthand evidence
‘Some people say I'm arrogant, but really 'm just about confidence
Everyone's involved when it comes to me
Did you say planning
poker? Customers dren’ involed in that activity
Trang 3gathering requirements Finally, you're ready to estimate the whole project tories, and alt with all
with your total project estimate Yex've got an estinate
Tor eath story now
Add an estimate to each user story for how long you think it will take to develop thar functionality
[1 Ate up att the estimates to get.a total estimate for hos
Trang 4489 days for the project?
‘That's almost two years!!! No kidding! That's way too long,
By the time youve developed the software, my competition will have beaten us into the ground!
What do you do when your estimates are WAY too long?
You've finally got an estimate you believe in, and that takes into aecount all the requirements that the
customer wants, But you've ended up with a monster project that is just goin, 1a take too long,
Is it time to go back to the drawing board? Do you admit defeat and hand the work over to someone eke? Or do you just ask the customer how long he thinks would work, forgetting about all your hard
work to come up with you estimates in the first place? You'll have to solve a crossword puzzle and work your way to Chapter 3 to find out how to get Orion's Orbits back on tack
Trang 5gathering requirements
S&B Requirements and Estimation Cross
Let's pul what you've learned lo use and stretch out your left brain a bit, All of the words below are somewhere in this chapter: Good luck!
'3, When coming up with estimates, you are trying to get rid of as 5, User stories are written from the perspective ofthe many 88 possible 6, When you and the customer act out a particular user story, 4, None ofthis language is allowed in a user story you are
7 Wa requirement is the what, an estimate is the 8 When everyone agrees on an estimate, itis called a 9 Requirements are oriented towards the 410 An estimate is good when eveyone on your team is
12 The best way to get honest estimates and highlight feeing
assumptions ‘1, The maximum number of days that a good estimate should 414, AUser Story is made up of and a description 45, ou 8 @ great way of getting frst hand evidence of exactly 13, A great user story i about ines long be for one user story,
how your customer works atthe moment 16, After around of planning poker, you plot all ofthe estimates
18, The goal of estimation is ona
17 You can use the rule for breaking up large user stories,
Trang 6your software development toolbox
Tools for your Software Development Toolbox Software Development is all about developing and
delivering the software that the customer actu: wants In this chapter, you learned about several techniques to help you get inside the customer's head and capture the requirements that represent what they really want For a comp! t of tools in the book, see Appendix ii
Development Techniques
Bluesky, Observation and Releplay
User Stories Sè
1 Blueskying gets your
Planning poker for estimation custome when coming up with thet to think big requirements ULLET POINTS
= Auser story captures one interaction with the software from the customer's perspective
‘= User stories should be short, around sentences in length
A short user story is an
estimatable user story Auser story should not take cone developer more than 15, days to deliver
iteratively develop your requirements with your customer to keep them in the loop at every step of the process
Trang 8
ea , Planning for success * Really darling, my software
development is so well planned Til be home on time every day for us to watch NASCAR together!
Every great piece of software starts with a great plan
In this chapter you're going to learn how to create that plan You're going to learn how to work with the customer to prioritize their requirements You'll define iterations that you
‘and your team can then work toward Finally youll create an achievable development plan that you and your team can confidently execute and monitor By the time you're
done, you'll know exactly how to get from requirements to your first deliverable
Trang 9deliver what you can, when it's needed
Customers want their software NOW!
want (heir sofiware when they need it, and nota moment Lat ips with the eu
Our Estimate What the customer wants
#14p The total after summing up all the 90 days!
estimates for your user stories
Well you obviously can't do everything that the customer wants in 90 days Why
not just cut back and prioritize?
Trang 10Orion's Orbits stil wants to modernize their booking system; they just can't wait almost two years forthe software to get finished Take the folowing snippets from the Orion's Orbits user stories, along with their estimatas, and circa the ones you think you should
develop to come up with chunk of work that will take no longer than 90 days,
vrs Booka shottle ‘wie Pay with Visa/MC/PayPal
stints 15 day states IF days nã Review flight 1B days ‘re Order in-flight meals ven 15 days Book Se AWAY in Spaceport transport Ghose seating Apply for “Frequent J days we View Space "+ Miles Account 1 I days astronaut” swe Manage special offers oman 12 ye Twa: eumee 12 days Take pet reservation
“etal ebmate ter 4Ì
of the wer we Jue eile
Trang 11priorities come from your customer
Our A Orion's Orbits still wants to modernize their booking system; they just can't wait for a year and
a half for the software to turn up Your job was to take the snippets on page 71 and keep the
‘ones you think you should develop Here are the stories we kept
pate The b6 sung "` “Ñ 4 tron if he imate, 15 đãƒt [gE sng to Tờ xe ba se Pay with Visa/MC/PayPal bookings at al Tee at te NS Tay ru ‘fake pet reservation summer |2 đê"
& Yum Book Seaway in space-port We
imate I5 days transport BA duy neh
sounded eel! This is how long things ook when we added vp all the estimates ) oxld Fit Bie
ee into fill | mẽ View Srace Miles Account cut the 40 days Manage special of Fer But that’s not whot I wanted at alll We showed the stories we chote to
peer Ss ‘The customer sets the priorities
Seems like the CEO of Orion's Orbits is not
happy, and ean you blame him? Afterall that hard work to igure out what he needs, we've som > ignoted him completely when deciding which
user stories take priority for the project
l When user stories are being prioritized, you
\ need to stay customer-focused Only the
customer knows what i really needed, So when it comes to deciding what's in and what’s
‘out, you might be able to provide some expert help, but ultimately it’s a choice that the customer has to make
Trang 12Prioritize with the customer
Is your customer's call as to what user stories take priority: To customer make that decision, shullle and lay out
the table Ask your customer to order the user sto st important to them fist) and d
to be delivered in Milestone 1.0 of their software 4p the Your user story cards on story at need
or Fight V9 rm Review Flight te Choose sea)
‘Avser willbe able to Bescroton: A user will beable to Besetplem, Â ĐBF VI vot a flight they have leave they have been on, a review for a shuttle flight shoose aisle or window
Lop ow days can I2 days
————
Pavwlth Vea Ma/Pavtal HB) an 0e men i "`
Users will be abe fo ‘Avaee will beable Beeaglem Austr Wil Ir bookings by credit Specify the meals and drinks they roche poritia sett
Pal ‘want dyrina a flight data an time of the f
ean 13 aye soe 15 dap
Lay out all your user stories tal sik the noone to
What is “Milestone 1.07? order them by priority
Milestone 1.0 is your first major release of the software to the customer, Unlike smaller iterations where you'll show the customer your software for feedback, this \will be the first time you actually deliver your software (and! expect to get paid for the delivery) Some Do's and Don'ts when planning Milestone 10:
DO issstetiecetincttonlity si cslexee impatience
be done in the time
ke it into Milestone 1,0 are not nil Milestone 2, or 3
>
Don't ce caught planning nice-to-haves
Milestone 1.0 is about delivering what’s needed, and that means set of functionality that meets the most important needs of the customer ignored, just postponed Don't , ,
ME suy dau km (yet) user stories Don’t get caught up on how long those user stories will Artis point youve tanking cudomer hít ane th ớt inpodadl 3729 A were not cttimation
take to develop You're just trying to understand the customer's priorities Néll ome right back te this
Trang 13bullding iiestone 1.0 We know what's in Milestone Ì.Ũ tải, mayna From all of th order, the của M io provity a part of
Sanity-check your Milestone 1.0 estimate
a know whi jer Wants in Milestone 0, nd out if you tí ngih of project if you deliver all of th features
‘All of the user stories
For Milestone 1:0 Estimate for
Trang 14If the features don’t fit, reprioritize
You've got 274 days of work for Milestone 1.0, and Orion's Orbits want delivery in 90 days Don't worry, this i pretty common, Customers usually want more than you can deliver, ‘your job to go back to them and reprioritize until you come up with a workable feature s To reprioritize your user stories for Milestone 1.0 with the custome! Cut out more FUNCTIONALITY The very
st thing you ean look at doing to shorten the tine to delivering Milestone 1.0 i teu out some functionality by removing user stories that are not absolutely crucial to the software working,
Ce Once You explain the schedule, most Cushomers will admit the Aim to deliver a signi development moment milestones
3 nats ne citerance between 2
milestone and a version?
Asner ntetyoucousal yor tek rset rae The
big diference between a milestone and a
which you deliver signicant software and get paid by your customer, whereas aversion is more of a simple descriptive term thats used to identity a particular release of your software
‘The diference i realy quite subtle, but the simple way to understand iti that Version” is labol and doesnt mean anything mere, whereas "Miestone' means you delver signficanttunctonalty and you get pid could be that Version 1.0 coincides with Milestone 1.0, but equal Milestone 1.0 could be Version 0,1, 0.2 or anyother abel you pek
Ship a milestone build as early as possible
anit milestone build of your software as ¢ up by allowing ye don't really need and your te Focus on the BASELINE functionality
Milestone 1.0 is all about delivering just the functionality working version of the software Any features beyond that can be sehe thereyare no Dumb Questions QO: ‘So what exactly is my software's baseline functionality? A rn tan tony sty Tonniam nsớt Ea
Think about a word processing application Its core functionality isto lt you load, edit, and save text to afl, Anything else is beyond core functionality, no matter how useful those features are Without the ability to oad, edit, and save a document with text init, aword processor simply is not useful, ‘Thats the rule of thumb: f you can get by without a feature, then itisnt really baseline functonalty, and is probably a (ood candidate for pushing out to a later milestone than Milestone 1.0 if you don't have time to get everything done,
ceded for a
everything they originally said they dd sy as possible This keeps your
m to focus on a dead that’s pot too far ol
Ce Dot let customers talk {yor inbo longer development
tyeles thân you're
Comfortable with The sooner
sr deadline, the more
Pesce you and your team tan be on it
led for later
3: te done the math and no matter how I cut the user stories up, | just can't deliver what my customer wants when they want me to, What can | do?
A? wine cas try
Tequied in the time that its needed by, and your customer simply won't budge when it ‘comes to removing some user stories from the mix then you might need to walk away from the project and know that atleast you were honest wit the customer
‘Another option isto ty to beef up your team ‘with new people to try and get more work done quicker However, adding new people to the team wil up the costs considerably, ‘and won't necessarily get you all the ‘advantages that you'd think it might
Trang 15
factoring in toam performance 76 Chapter 3 Hello?! Can't we just add some more people to cut down our estimates? Add two developers, and well get done
in 1/3 the time, right?
IF it takes you 273 days, with 2 more eotle like you, that would vedute the overall development time by a factor of 3, vight?
It's about more than just development time
While adding more people can look really attractive at first, is really not as simple as “double the people, halve the estimate
Every new team member necdls to get up to speed on the project: they need to understand the software, the technical decisions,
and how everything fits together, and while they're doing that they can't be 100% productive
Then you need to get that new person set up with the right tools and equipment to work with the team, ‘This could mean buying new licenses ‘and purchasing new equipment, but even if it just means downloading
some free or open source software, it all takes time and that time needs to be factored in as you reassess your estimates,
Finally, every person you add to your team makes the job of keeping everyone focused and knowing what they are doing harder; Keeping, everyone moving in the same direction and on the same page become a full-time job, and as your team gets larger you will find that
Mì start to hit your team’s averall ability to
this complex communi
be productive and develop great software
In fact, there isa maximum number of people that your team ean contain and still be productive, but i will depend very much on your project, your team, and who you're adding, The be
‘monitor your team, and if you start to see your team actually get less productive, even though you have more people, then it’ time to
re-evaluate the amount of work you have to do or the amount of time in
approach is to
Which you have to do it
Later on in thit chapter you'll be introduced Me ‘tool for monitoring the ria sella of Your to the bum-down vate graph This ix a great
Trang 16More people sometimes means diminishing returns
‘Adaling more people to your team docsn'talways takes 2/4 days to complete Milestone 1.0, then $ people wont necessarily take 91 Ìn work as youd expect, If person
fact they could actually tale much longer! Teke'a ook perormance doesn’ abaya, inerease withthe size of your tea DÝđ3 se point, adding extra people Aboct here, your team's performance starts to max out Performance er vate of development work actually being done
For small Leams, and
when startup and
setup time is factored
1 im You Can see 2 bi i improvement when > U ‘adding extra people Zot St “ eee People eae, Dumb Questions
QQ tetnere a maximum team size htt should never go over?
‘A ecm cere may fn that you can happily handle a 20-peson team, pata POWER RAL
but that things become impossible when you hit 21
‘Alternatively you might fin that any more than three Do you think the size of your project affects developers, and you start to see a dip in producti The this graph? What about if you broke your
project up into smaller sub-projects? best approach is to monitor performance closely and
‘make amendments based on your observations,
Trang 17
building achievable milestones
Work your way to a reasonable Milestone 1.0
With Orion’s Orbits, going from one person to three more developers —ca
works out
First you add two new peo}
Adding two developers to your team (that’s
by adding two hhave a positive impact So let’ see how that
you) helps, but it’s not a magical solution, Two developers can add a lot of work time to your project, but there's still work left a4 Now you' time, and fe got a nice way to fi = 190 days |= 3, developers 94 days
Days of work that your team of 3, can hung
im 90 calendar days to do!
hen you reprioritize with the customer
te out what has to be removed We've got 189 days of work 3 days of work So we need to talk to the customer and remeve around £4 days ‘of work by shifting out some user stories from Milestone 1.0 ZB days of work to do Dum Qt 190 days of works ess than the 190 days that ou Pesca teeplabnlyrebon ch lg sors airs wh case?
A tie oat esate oer acy have ote exact 188 days Given that we'e dealing with estimates anyway, which are
rarely 100% accurate, an that we tnd tobe shghly optimistic n ‘ur estimates then 165 days is close enough to the 189-day mark to be reasonably confident of delivering in that te 78 Chapter3 Customer removed features therelareno „ b Qnestions = 184 days
Looking better, with a few days
left over to give you a bit of breathing naặc in your milestone
sow ad you come up wth 190 days when you added
two new developers?
A: ais pit is runbri a quasdmale Veke gna thal adding two people to bul team of three wil mean we can
do around 190 days of work in 90 calendar days There are ways to backup this guess with some evidence using something called
“team velocity," but we'll get back to tha ater on inthis chapter
Trang 18Functionality [f a feature isn't BE the Cusfemer <_— _ events, 2 probably net a 10
Now it’s your chance to be the customer You need to build a plan for when you are going to develop each of the user stories for Milestone 1.0, and to do that you need to ask the customer what features are most important so that you
can develop those first Your job is to play the eustomer by men a priority to the Milestone 1.0 user stories For each user story, assign it a ranking in the square provided, depending on how Đệ tho think that feature is using the Key at the bottom of the page
Order In-flight meals crave: Login to "Frequent Astronaut” account te 15 days The: ais POY using “Space Miles” se 15 days ‘rae: Manage special offers Tớ gác DB days — — TL] sree View flit ue Pay with Visa/ MéPayfal xe IS SMM€ MS account xà reviews Điển xà Ea te Hán cu — me ‘rai: Apply for “frequent
Priorities Key que Choose seating ho To
10 - Most Important we Tha fon I days
20 đ rite (oh
-
30 ‘rive: View shuttle deals For each user story,
Trang 19your customer decides priority
Our, thereareno „
“BE the Customer Selufion Dumb Questions
‘Your job was to play the customer and prioritize the
Milestone 1.0 user stories Here are the priorities +40, and 50? 5 wy are te priorities 10, 2,20 that we assigned to each of the user stories
‘We also [aid out the user stories in order of A\: ower ot ten gett rin inking about groupings features, stead Order of priovity, most to least Cf ordering each and every feature
separately with numbers tke 8 or 26 or 42 You're trying to get the customer to ‘decide what is most important, but not I {get too hung themselves Also, powers often allow up onthe exact numbers
‘rms: , View shuttle deals, | Review flight ve
important to the customer 1
you to occasionally spect, say, a 25 for a particular feature when you add tats 13 days ‘ something in later, and need to squeeze
suy: ba] \ it between existing features,
QQ tesa, tnen maybe we can leave it out righ?)
eau 12 days I /
A wo so dont mean ata er stot is a candidate for leaving ou At this pont, we're working onthe user stores fr Milestone 1.0, and so these astronaut” card user stories have already been ilered oa eae <own othe customer's most important features The goa here isto piottzo, not figure out any ofthese features aren't important So a 50 just says it can come later, not that t's nt important to
al
ˆ_ Agtronanf amamt 15 days |B te customer
i 1
¬
“rit: View “Space Miles” A: Assign a priority of 60 to those
account [BE atts fornon, 0 they dont get ize in ‘uth your Milestone 10 features,
3 na tne customer does a this
wort?
A: Yorn rep ot aati maybe mentoring dependencies
between some ofthe user stores But the tinal decision on prnbes is aways the customer’ to make
Trang 20
‘Now that you have your user stories for Milestone 1.0 in priority order, it's time to build some iterations Lay out the user stories so they make iterations that make E€RCÌS6 senso to you Be sure and write down the total days of work, and how long that
Trang 21milestone = paid, iteration = on track Fireside Chats
ae
Milestone:
Hello there, iteration, seems like its only been a month since I saw you last
So how are things going on the project? Its like you're always showing up, and T just the big finish Actually, what's your purpose?
Naive? Look, just hecause I've had a few customer run-ins before doesn’t mean I'm not important
‘mean, without me, you wouldn't have software at all Jetalone get paid! Besides, just because Pe shown ‘up and surprised the occasional customer from time
to time
Tused to try that, too, Pd try andl soften the blow by explaining to the customer that all of their problems would be fixed in the next yersion of the software, Fut that wasn't what they wanted to hear Lats of yelling, and 1A slink off, ready to go back to work fora year or so, and see if the customer liked me 82 Chapter3 Tonight's talk: A sit-lown discussion between an iteration and a milestone Iteration:
Almost exactly a month, And you'll see me a next month, Í can guarantee it, About three times, and we're ready for you, Milestone 1.0,
"To make sure things go great, of course, ‘That's my job really, to make sure that every step of the way finm day 1 to day 90, the project stays on track
‘What, you thought you could just show up three ‘months into the project and everything would be just like the customer wants it? A bit naive, aren't you?
Trang 22
Yel, Fry co be, bút son just how long it takes, although T just love seeing the customer more often Atleast once a quarter seems to line up with their billing eycles And not so long that I get forgotten about; there’s nothing worse than that
Are you kidding? You're not even an alpha or a beta just some code glued together, probably an excuse for everyone to Wear jeans to work and drink beer on Friday afternoon,
Ha! Where would I be? Same place Tam right now, getting ready to show the customer some real itware, wait He hopes for you, you litle, ally? Poe wot a few Ungrateful little punk, release this!
Yeah, nobody forgets about me Around every
month, there Tam, showing up, putting on a song
and dance, pleasing the eustomer Really, Ï can
imagine how you ever got by without me,
Oh, i's tle more than that, don’t you think? Where would you be without me paving the way, making sure we're on track, handling changes and new features, and even removing existing features that aren't needed any more
hopefully working?
‘Well, you got the litle part right, Why don't you just shullle off for another 30 days or so, we'll eall you ‘when all the work's done Then we'll see who Friday beers are on, OK?
Sure thing, and since T do my job, Pn sure you'll ‘work just fine Pm outta here, plenty of work lel wo
be done
Trang 23
continuously buildable and runinable
Your answers could be ‘Your job was to lay out the user stories so they make iterations that make sense Here's what we came up with note that all our iterations are within one sure you went in different, but make calendar month, about 20 working days (or less) edet of priority % ution .—- =
wie Manage special | mer Book ashottle | rwe Pavwith Visa/ | view Shuttle
offers MC/Payéal Mab et: B days ee IF dap ean 15 das mm Mã = Iteration | mem [lô] — BỊ make sure you kept your Lm hạt a Total Daye wes Choose seating | sig, Order Inflight | Timer Review flight | „ View flight reviews meals for ID doy au TB days m Bán tảng -¬ mmm [| me BO] | Bộ] Iteration 2 Tetal Daye £50 | Divide by 3 developers: {|} wie: Apply for“frequent ye, Loginto “Frequent | rae: View “Space Miles) tie: Pay using
astronaut” card ‘Astronavt” account account “Space Miles”
Hung: eon 15 days eon days Shih
Iteration 3 Total Days
What do you think you should do at the
end of an iteration? cho, the customer and get their feedback
util Ghestions —— Keep your software continuously sáetansealen maleemtwe —_ | building and your software
acting 3 Shei easionert always runnable so you can
A soy i cs em a not have something to show the customer iif no user stories were always get feedback from the
completes during te ieraton youve managed to do tis then yor | customer at the end of an
projects out of conrl and you need to get things back ontrack as S2 ất
quCHỰ 83 possible iteration
Trang 24
Herations should be short and sweet 30-day iterations, with
different size iterations, ea faulty Milestone 1.0 next iteration, t 9 Keep iterations balanced
on should be a balance between dealing with change
ures, beating out bugs, and accounting for real :
ing If yo have Ì nh deen ge cara are basically 30, CALENDAR days adding new people wi really 30 which you an assume turn Be ahnt 20 WORKING of a ductive
SHORT iterations help you deal with change and keep you and your team motivated
and focused
Trang 25bringing reality to your plan
Sacaloaal
-—————— ‘wnte woes w: +
aspect of a user story, iteration, milestone or perhaps two, or even all three! Your job is to check off the boxes for the different things that each aspect applies to
User story iteration Milestone
I resul in a buildable and runnable bit
of software Oo o O
Tm the smallest buildable pieee of {na full year, you should deliver me a maximum of four times,
contain an estimate set by your team,
Trang 26Comparing your plan to reality
Tt looks like well be doing fine on the plan as long as we can ll fit in a full five-day week ® Bob: Laur: dh, just so you know, Nick is coming in at 11 today What? Bob: Oracle 9 on my machine this afternoon, so you mi
id while we're talking, the I guys are want to keep that in mind, to
Laura:
should be aware of
nasty surprises in there that I Bob: Well, | have got a week of vacation this month, and, then there's Labor Day to take into account
Laura: Perfect, how can we come up with a plan that factors all these overheadl in so that when we go get as signolf from the CEO of Orion's Orbits we know we
have a plan we can deli
De You think cur current 20
workday iteration Lake thea
sorts of les nh :
corp yur pred — we See if you can help Bob out Check all the things that you need to account for when planning your iterations
Paperwork Equipment failure H ma
H sa [1 Software upgrades [| Frank winning
Trang 27
velocity applies your real performance
n WHO DOES ` 2 WHAT? a
Luton jon, milestone, or
Below isa particular aspect of a user story, iter
perhaps two, or even all three! Your job is to cheek off the boxes for the different things that each aspect applies to
User Story, iteration Milestone Oo a B software Ina fully
Í contain an estimate set by your team, | contain a priority set by the customer When I'm done, you deliver sofiware to the customer and get paid,
oO M
Oo oO
1 should be done and dusted
~ @qQharpen your pen’ £§$£@—@@ = See if you can help Bob out Check all the things that you need to
account for when planning your iterations a Things ke ie gh ike this always ceeur so-we have to plan for thon
Trang 28Velocity accounts for overhead in your estimates
Is time to add a little reality to your plan, You need to factor in all thos bits of overhead by looking at how fast you and you
And that’s where velocity comes in, Velocity is a perentage: given X number of days, how much of that time is productive work? actually develop s
But how can T know how fast my team performs? We've only
Just gotten started!
Start with a velocity of 0.7 On the
that your team’s
first iteration with a new team it’s fair 10 assume ‘ime will be about 71
their available time, ‘This means your team has a velocity value of 0.7 In othe for every 10 days of work time, about 3 of those days will be taken up by holidays, sofiware installation, paperwork, phone calls, and other nondevelopment tasks That's a conservative estimate, and you may find that over Yet another reason to have short iterations e can adeat velocity frequently
time, your team’s actual velocity is higher: IF that's the ease, then, at the end of your current iteration, you'll adjust —
eto determine how ‘many days of work can go into the next iteration your velocity and use that new
Best of all, though, you can apply velocity to your amount of work, und get a realistic estimate of how long that work will actually take
The result should al v
Take the days of werk it will take you levelop 2 wier stov'y, or an iteration, days of the eviginal days of work, to account
Cc days of work = days required to
> velocity get work done
and DIVIDE that umber by your SS i? 30 days of a calendar ae
velocity, whith should be ketene Seeing a trend tat a
TØ St vậy 0 g0 2 © aed xonth was really 20 days oF werk, and
: Sood Conservative estimate, na new Project: as TO days of work is really onty about & ie of produttive time
Trang 29
from idoal to roal estimates
Programmers think in UTOPIAN days
Ask a programmer how long it takes to get something done, like writing a PHP interlace to:a MySOL database, of maybe sereen-scraping World Series scores from espn.com, They've going to give you a better-than-best-case estimate
Here’s what a programmer SAYS
‘Sure, no problem, I can crank ‘through that in two days 5
Most developers assme they're the only
Peerle involved, that theyll
that testing it someone else's eb, d make no mistakes,
„„bU† heres what he’s really THINKING
Tll grab a Monster on the way home, program till 3 ‘AM take @ Halo break then work through the morning Sleep a few hours, get the guys over to hack with me, ‘and finish at midnight As long as nothing goes wrong ‘and Mom doesn't need me to pick up dinner:
Ầ Bek her ese ace jk the net the developer knows about! cece are about [0 assumptions im
Trang 30Developers think in REAL-WORLD days To be a software d got a team of late, e depending estimates are more conservative, and take into account real life:
to deal with reality You've probably who won't pay you if you're
so your
You start with a month, but take
anay weekends and holidays
tity to account, For
Then, at vd foewsed
ime in tre office that vant
days ers cbual development
— |4 days of REAL work
This is 3 lot lower number of days, but you an be more CONFIDENT in the rachel
pla page 84 and apply 70% velocity 30 that you can come up with nh nan
Trang 31confidence comes at a price
When is your iteration too long?
© you have three developers on your team who are working at a velocity of 0.7 This :mieans that (o calculate how long an iteration will really take your team, you need to apply your velocity to the iteration’s estimate
Yes, these estimat
~Ƒ makes ave getting
Iteration | longer but: you're bulding confidence
sta /or= BL days 9s x Heration 2 _ 0 days / ore 2 days ¬.-.—- day target s8 day 07 = 63 days —) = 237 days of work
So if you have 3 developers, each of them has to work 79 days in 3 months but there are only 60 working days Ione oS people, we still can't deliver Milestone 1.0 in timel
How would you bring your estimates back to 20 work-day cycles so you can deliver Milestone 1.0 on time,
without working weekends?
Trang 32Deal with velocity BEFORE you break into iterations
A lot of this pain could actually have been avoided if you'd applied velocity at the beginning of your project By applying velocity up front, you can calculate how many days of work you and your team can produce in each iteration, Phen you'll know exactly what you can really deliver in Milestone 1.0
First, apply your team velocity to each iteration By taking the number of people in your
|, multiplied by the number of actual working
cealeulate how
days in your iteration, multiplied finally by your team’s velocity, you ¢
mang days of actual work your team can produce in one iteration 3 x20 x©.}= 42 ANH days in ‘your iteration The ao of
eagle on your team gents te velo team's First iC The amaunt of work, in erson-days, that your team
= = ki tan handle in one iteration Add your iterations up to get a total milestone estimate
Now you should estimate the
multiply your days of work pe imber of iterations you need for your milesto tions, and you've got the Just
ation by the number of ite
number of working days you can devote to user stories for yo
42%3 = Number of “ra in days that
iterations in Yyou and your team can do before Milestone 1.0 Milestone |.0 needs to be shiyyed:
Dum 3 that sucat 801 ony have 14 day of actual productive work pe eration i my veloc is 07?
A: 071 cco ‘of Your eam coming up to speed and other overheads As you and stan trvlanp coy wens
your team complete your iterations, you' Keep coming back to that velocty value and updating it to reflect how productive you realy re
thereyare no
bo Questions
QQ mt veicty, my testne 19 now going t take 79 working day, which means 114 calendar days That's much ‘more than the 9-day’-month deadin that Orion's Orbits set, Fan that too long?
‘A: es v's cis ee etn 100 caer as, by applying velocity, you've now got oo much work todo to meet thai
Trang 33iterations with velocity
ng Exercise
‘When your iterations contain too much work for your team, there's nothing else to do but reshuffle work until your iterations are manageable Take the Orion's Orbits Milestone 1.0 user stories and organize them into iterations that each contain no
The maximum amount of more than 42 days of work work your team Can do in 2
JE iteration factoring a
10-day
in qour velotity thi time
so View sb0ttle | yaaa: Booka shuttle, Tm aywith Visa deals P Mg/Pg | tom Mama ei ‘i
en U2 days ou l5 eon 15 days ee
et, me a
~~ Remember to respect the tastomer's original order of
⁄ SH eae grey n your arabs V Pe eS ve me: Choose seating nam Order In-flight, | Tate Review flight View flight reviews meals wu Lada ee DB days eon Tia `" ` ee BỊ v
‘we: Apply for“frequent sy, Login to “Frequent | re: View “Space Miles) rie: Pay using astronaut” ard Astronaut” account account “Space Miles”
các days cow 15 dap eon days `
Trang 34Plan out each iteration by adding user stovies that come out to around 42 days of work \ ` Iteration 2 ; — / ; “ E7 BH my ⁄ — —
that won't Iteration 3
user stories that wor
Trang 35reality moans being honest
É ExeRel§8 AAA
Ạˆ= Your job was to to take the Orion's Orbits user stories and aim for iterations that contain no more than 42 days of work each, sw: View shuttle aim Booka shuttle re Pay with Visa/ deals Mt/fayPa| ese 12 days sae 15 days ese 15 days tuy may Iteration | Total Days of work ‘rue: Manage special ‘rae: Choose seating ies Order Inflight offers Talk sexe 1B days jee 12 days ` any me b2] — bạ Iteration 2 Total Days of work: 13g
‘res Review flight ` reviews we: Apply for Space
Miles Loyalty Card aw 12 days ew da row [30] Pen tteration 3 Total Days of work fan DB days These user stories dropped off of the plan As
xe Login to “Frequent, ‘rine: View “Space Miles” ‘rote: Pay sing
Astronaut” account account “Space Miles”
`: w Ihe days `
vee Fl xe» | mer ea]
Trang 36Time to make an evaluation
So what's left? You've probably got a lot of user stories that still fit
into Milestone 1,0 and maybe a few that don't, That's because we Estimates without
dldn’t figure out ou velocity belore our iteration planning <—— Your Customer get you into real trouble wi hut velocity can ol) mies witha , Ê ‘rive; Manage | ‘ive: View flight reviews ™ ‘vite: Pay using “Space Miles” eae 15 days ‘rite Choos! re Review flight ä tee ID day rane — [) eB dope wore” Bo)
Milestone 1.0 Milestone Next ——
All the werk bratty n be done for" 4 reise ate that fell ovt of
Mlebee LÒ Milestone 10
Deliver the bad news to the customer I's the time that every software developer dreads, You've planned out your iter tored in the veld
team, but you still ‘everything your custon done in time for their deadline There's nothing else to «lo but come clean n't
That sucks! So yeu can do everything except the online “Space Miles" features
Hmm Let me think about i
° BS
°
There's no magic trick here you have to tell the
ashomer and see what they want you are here» 97
Trang 37
breaking realistic but bad news “(— teoenbsbk cdmes] ENote From human rerourtes: we prefer the
Mawaging pisøtEs£f eU$†0t6rs
‘Customers usually aren't happy when you tell them you can't In the time they want, Be honest, though; you want to come up with a plan for get everything done Milestone 1.0 that you can achieve, not a plan that just says what the customer
Wants it to say Km "`
So what do you do when this happens?
Irs almost inevitable that you're not going to be able to do everything, soit helps to be prepared with some options when you have to tell the custo
the bad news
© Add an iteration to Milestone 1.0
Explain that the extra work ean be done i additional iteration is added to the plan ‘That
a longer development schedule, but the customer will get what they want in Milestone 1.0
42 x3/= Ig
eam ylenty of time
‘mother iteration gives Your team fl
do develog al the Customer's stories be bat
pushes ovt the release date of Milestone
© Explain that the overflow work is not lost, just postponed
Sometimes it helps to point out that the user stories that can't make it into Milestone 1.0 are not Jost; they are just put on the back burner until the next milestone TÍ= xa , a Ae 1 trashed they jot Fall into “These extra stories aren't em ner letone 2.0 Me shếc mÌ ng in so impor important that theyre —= Milestone Next- wert starting oer with 8 new development team’
‘Milestove
© _ Be transparent about how you came up with your figures
Ii sounds strange, but your customer only has your word that you ca they want within the deadline t
coming from If you equates to th
and that why you've fle that you ean ch
deliver everything “ve given you, so it sometimes helps to explain where you're show them the calculations that back up your velocity and how this And tell your customer you eant to deli successful software,
Trang 38puimb Guestions
QS ttm ise on my estimates, can fudge atte and squeeze something in?
A\: wera wuts recomend tis Renter, your ‘estimates are ony educated guesses al his point, and they are
actualy mre they to ake slighty longer than ơiglnaly thought han shorter
it's much beter idea to leave some breathing room around your estimates to really be confident hat youve planned a successful set iterations
3 shave te day tt ovr in my Milstne 1.0 cant ad
in a.user story that breaks my day limit just a little bit?
A: ‘Again, probably nota good idea It your stories add up to leave you one or two days at the end of he eration, that's OK (In Chapter 89 wel talk about what you can do lo round those out)
QQ ox, without squeezing my st ne story in and up coming under my workday limit by a LONG way have 15 days treat the end of Milestone 1.0 there anything ean do about that?
(A totea sry at spc, y adc p wth ost ‘snow and it notes leone 19d
5 seams to add up oa LT of stn What ot of acives coud ake up tat sor fine?
A: 07s sale tgp st ts wl Ov xno where you ae installing @ new piece of software, ike an IDE or @
database (naming no specific manufacturers here, ofcourse) In cases lke these two hours of interrupted work can actually mean FOUR hours of lost ime when you factr in how longi can take a developer to get back in the zone" and developing productively It also worth bearing in mind that velocity is recalculated atthe
lend of every iteration So even if 0.7 seems low for your team right, ‘ow, you'l be able to correct as Soon as you have some hard data ‘In Chapter 9 we'l be refining your velocity based on your team's performance during iteration 1
Alvight, its worth it te me to lose space miles in Milestone 10 to keep things moving Let's do it
Stay confident that you can achieve
the work you sign up for You should
promise and deliver rather than
overpromise and fail
Trang 39
Introducing the big board
The Big Board on your wall
‘Once you know exactly what you're building; it's dashboard for lt of y User stories for Iteration | 100 Chapter 3
ime Wo set up your software development on 1 of development Your dashboard is actually just a big board on the wall
Trang 40
Usually your project: board is a whiteboard, :0 you cặn
£ ste it again and again betmeen iterations and projects
| Any user stories for this iteration that won't fit on the
I leFt ave put here