Software Development Cross Solution - Index of - Free

your estimates are your promise
Q: How can I tell when my estimates are close enough,
and have really converged?
A: Estimates are all about confidence. You have a good
estimate if you and your team are truly confident that you can
deliver the user story’s functionality within the estimate.
Q: I have a number of assumptions, but I still feel
confident in my estimate. Is that okay?
A: Really, you should have no assumptions in your user
stories or in you and your team’s understanding of the customer’s
requirements.
Every assumption is an opportunity to hit unexpected problems
as you develop your software. Worse than that, every assumption
increases the chances that your software development work will
be delayed and might not even deliver what was required.
Even if you’re feeling relatively confident, knock out as many of
those assumptions as you possibly can by speaking to your team
and, most importantly, speaking to your customer.
With a zero-tolerance attitude to assumptions, you’ll be on a
much more secure path to delivering your customer the software
that’s needed, on time and on budget. However, you will probably
always have some assumptions that survive the estimation
process. This is OK, as assumptions are then turned into risks
that are noted and tracked, and at least you are aware of those
risks.
Your estimates are your
PROMISE to your customer
about how long it will take you
and your team to DELIVER.
58 Chapter 2
Download at WoweBook.Com
Q: I’m finding it hard to come up with an estimate for my
user story, is there a way I can better understand a user story
to come up with better initial estimates?
A: First, if your user story is complicated, then it may be too
big to estimate confidently. Break up complex stories into simpler
ones using the AND rule or common sense.
Sometimes a user story is just a bit blurry and complicated.
When that happens, try breaking the user story into tasks in your
head—or even on a bit of paper—you’ve got next to you at your
planning poker sessions.
Think about the jobs that will be needed to be done to build that
piece of software. Imagine you are doing those jobs, figure out
how long you would take to do each one, and then add them all
up to give you an estimate for that user story.
Q: How much of this process should my customer
actually see?
A: Your customer should only see and hear your questions,
and then of course your user stories as they develop. In particular,
your customer is not involved in the planning poker game.
Customers will want lower-than-reasonable estimates, and can
pressure you and your team to get overly aggressive.
When there is a question about what a piece of the software is
supposed to do in a given situation, or when an assumption is
found, then involving the customer is absolutely critical. When
you find a technical assumption being made by your team that
you can clarify without the customer, then you don’t have to go
back and bother them with details they probably won’t understand
anyway.
But when you’re playing planning poker, you are coming up with
estimates of how long you believe that your team will take to
develop and deliver the software. So it’s your neck on the line,
and your promise. So the customer shouldn’t be coming up with
those for you.