Software Development Cross Solution - Index of - Free
Software Development Cross Solution - Index of - Free
Software Development Cross Solution - Index of - Free
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Q: Why is there a gap between 40 and<br />
100 days on the planning poker cards?<br />
A: Well, the fact is that 40 is a pretty<br />
large estimate, so whether you feel that the<br />
estimate should be 41 or even 30 days is<br />
not really important at this point. 40 just says<br />
that you think there’s a lot to do in this user<br />
story, and you’re just on the boundary <strong>of</strong> not<br />
being able to estimate this user story at all...<br />
Q: 100 days seems really long; that’s<br />
around half a year in work time! Why have<br />
100 days on the cards at all?<br />
A: Absolutely, 100 days is a very long<br />
time. If someone turns up a 100-days<br />
card then there’s something seriously<br />
misunderstood or wrong with the user story.<br />
If you find that it’s the user story that’s<br />
simply too long, then it’s time to break that<br />
user story up into smaller, more easily<br />
estimatable stories.<br />
Q: What about the question-mark<br />
card? What does that mean?<br />
A: That you simply don’t feel that you<br />
have enough information to estimate this<br />
user story. Either you’ve misunderstood<br />
something, or your assumptions are so big<br />
that you don’t have any confidence that any<br />
estimate you place down on the table could<br />
be right.<br />
Q: Some people are just bound to pick<br />
nutty numbers. What do I do about them?<br />
A: Good question. First, look at the trends<br />
in that individual’s estimates to see if they<br />
really are being “nutty,” or whether they in<br />
fact tend to be right! However, some people<br />
really are inclined to just pick extremely high<br />
or very low numbers most <strong>of</strong> the time and<br />
get caught up in the game. However, every<br />
estimate, particularly ones that are out <strong>of</strong><br />
whack with the rest <strong>of</strong> the player’s estimates,<br />
should come under scrutiny after every<br />
round to highlight the assumptions that are<br />
driving those estimates.<br />
After a few rounds where you start to realize<br />
that those wacky estimates are not really<br />
backed up by good assumptions, you can<br />
either think about removing those people<br />
from the table, or just having a quiet word<br />
with them about why they always insist on<br />
being <strong>of</strong>f in left field.<br />
Q: Should we be thinking about who<br />
implements a user story when coming up<br />
with our estimates?<br />
A: No, every player estimates how long<br />
they think it will take for them to develop<br />
and deliver the s<strong>of</strong>tware that implements the<br />
user story. At estimation time you can’t be<br />
sure who is going to actually implement a<br />
particular user story, so you’re trying to get<br />
a feel for the capability <strong>of</strong> anyone on your<br />
team to deliver that user story.<br />
Of course, if one particular user story is<br />
perfect for one particular person’s skills, then<br />
they are likely to estimate it quite low. But<br />
this low estimate is balanced by the rest <strong>of</strong><br />
your team, who should each assume that<br />
they are individually going to implement that<br />
user story.<br />
In the end, the goal is to come up with an<br />
estimate that states “We as a team are all<br />
confident that this is how long it will take any<br />
one <strong>of</strong> us to develop this user story.”<br />
Q: Each estimate is considering more<br />
than just implementation time though,<br />
right?<br />
A: Yes. Each player should factor in how<br />
much time it will take them to develop and<br />
Download at WoweBook.Com<br />
gathering requirements<br />
deliver the s<strong>of</strong>tware including any other<br />
deliverables that they think might be<br />
needed. This could include documentation,<br />
testing, packaging, deployment—basically<br />
everything that needs to be done to develop<br />
and deliver the s<strong>of</strong>tware that meets the user<br />
story.<br />
If you’re not sure what other deliverables<br />
might be needed, then that’s an assumption,<br />
and might be a question for the customer.<br />
Q: What if my team all agree on<br />
exactly the same estimate when the cards<br />
are turned over. Do I need to worry about<br />
assumptions?<br />
A: Yes, for sure. Even if everyone agrees,<br />
it’s possible that everyone is making the<br />
same wrong assumptions. A large spread<br />
<strong>of</strong> different estimates indicates that there<br />
is more work to be done and that your<br />
team is making different and possibly large<br />
assumptions in their estimates. A tiny spread<br />
says that your team might be making the<br />
same assumptions in error, so examining<br />
assumptions is critical regardless <strong>of</strong> the<br />
output from planning poker.<br />
It’s important to get any and all assumptions<br />
out in the open regardless <strong>of</strong> what the<br />
spread says, so that you can clarify those<br />
assumptions right up front and keep your<br />
confidence in your estimates as high as<br />
possible.<br />
Don’t make<br />
assumptions about<br />
your assumptions...<br />
talk about<br />
EVERYTHING.<br />
you are here 4 53
Change language