Software Engineering - Midterm

What happens when a change occurs and my plan needs to change?

Change is unfortunately a constant in software development, and any process needs to handle it. Luckily, an iterative process has change baked right in.

The last feature scheduled for my iteration will push the time needed to way over a month. What should I do?

Consider shifting that feature into the next iteration. Your features can be shuffled around within the boundaries of a 20-day iteration until you are confident that you can successfully build an iteration within the time allocated. Going longer runs the risk of getting off course.

How can I tell when my estimates are close enough, and have really converged?

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.

When a user story's estimate breaks the 15-day rule you can either:

Estimates greater than 15 days per user story allow too much room for error. When an estimate is too long, apply the AND rule to break the user story into smaller pieces.

Iteration..

Every time you make significant progress you'll check with the customer and refine what you're working on. You also don't make any major decisions without incorporating customer feedback.

Who should be involved in an iteration?

Everyone who has a say in whether your software meets its requirements, and everyone who is involved in meeting those requirements. At a minimum, that's usually your customer, you, and any other developers working on the project.

Priority

Factors of 10. 10 is the most important, the higher the less important

"double the people, halve the estimate."

False Every new team member needs 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.

Each estimate is considering more than just implementation time though, right?

Yes. Each player should factor in how much time it will take them to develop and deliver the software including any other deliverables that they think might be needed. This could include documentation, testing, packaging, deployment—basically everything that needs to be done to develop and deliver the software that meets the user story. If you're not sure what other deliverables might be needed, then that's an assumption, and might be a question for the customer.

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?

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.

If I'm close on my estimates, can I fudge a little and squeeze something in?

We REALLY wouldn't recommend this. Remember, your estimates are only educated guesses at this point, and they are actually more likely to take slightly longer than originally thought than shorter. It's a much better idea to leave some breathing room around your estimates to really be confident that you've planned a successful set of iterations.

Why is there a gap between 40 and 100 days on the planning poker cards?

Well, the fact is that 40 is a pretty large estimate, so whether you feel that the estimate should be 41 or even 30 days is not really important at this point. 40 just says that you think there's a lot to do in this user story, and you're just on the boundary of not being able to estimate this user story at all...

My tasks add up to a new estimate for my user story, so were my original user story estimates wrong

Well, yes and no. Your user story estimate was accurate enough in the beginning to let you organize your iterations. Now, with task estimates, you have a set of more accurate data that either backs up your user story estimates or conflicts with them. You always want to rely on data that you trust, the estimates that you feel are most accurate. In this case, those are your task estimates.

Ordering things by customer priority is all fine and good, but what happens when I have features that need to be completed before other features?

When a feature is dependent on another feature, try to group those features together, and make sure they are placed within the same iteration. You can do this even if it means doing a lower-priority feature before a high-priority one, if it makes the high-priority feature possible.

Put assumptions on trial for their lives

When it comes to requirements, no assumption is a good assumption. So whenever planing poker turns up your team's assumptions, don't let that assumption into your project without first doing everything you can to beat it out of your project... Aim for as little assumptions as possible, that way at least you know what you dont know and you can go back to the customer

The customer sets the priorities

When user stories are being prioritized, you need to stay customer-focused. Only the customer knows what is 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.

Bluesky with your customer

When you iterate with the customer on their requirements, THINK BIG. Brainstorm with other people; two heads are better than one, and ten heads are better than two, as long as everyone feels they can contribute without criticism. Don't rule out any ideas in the beginning—just capture everything. It's OK if you come up with some wild ideas, as long as you're all still focusing on the core needs that the software is trying to meet. This is called blueskying for requirements.

Assumptions bad

While you can't always get rid of all assumptions, the goal during estimation is to eliminate as many assumptions as possible by clarifying those assumptions with the customer. Any surviving assumptions then become risks.

My entire project is only two months long. Is it worth iterating for such a short project?

Yep, iteration is still really useful even on a very short project. Two months is a whopping 60 days of chances to deviate from the customer's ideal software, or misunderstand a customer's requirement. Iteration lets you catch any potential problems like this before they creep into your project. And, better yet, before you look foolish in front of your customer.

With velocity, my Milestone 1.0 is now going to take 79 working days, which means 114 calendar days. That's much more than the 90-day/3-month deadline that Orion's Orbits set, isn't that too long?

Yes! Orion's Orbits need Milestone 1.0 in 90 calendar days, so by applying velocity, you've now got too much work to do to meet that deadline. You need to reassess your plan to see what you really can do with the time and team that you have.

And I'm supposed to do all this refining of the requirements as user stories with the customer?

Yes, absolutely. After all, you're only ready for the next step when both you and the customer finally decide that you completely understand the software requirements. You can't make that decision on your own, so keeping your customer in the loop is essential.

If I add more people to the project, couldn't I do more in each of my iterations?

Yes, but be very careful. Adding another person to a project doesn't halve the time it takes to complete a feature.

What if my team all agree on exactly the same estimate when the cards are turned over. Do I need to worry about assumptions?

Yes, for sure. Even if everyone agrees, it's possible that everyone is making the same wrong assumptions. A large spread of different estimates indicates that there is more work to be done and that your team is making different and possibly large assumptions in their estimates. A tiny spread says that your team might be making the same assumptions in error, so examining assumptions is critical regardless of the output from planning poker. It's important to get any and all assumptions out in the open regardless of what the spread says, so that you can clarify those assumptions right up front and keep your confidence in your estimates as high as possible

In order to handle change in an iteration..

1. Estimate the new features 2. Have your customer reprioritze the features 3. rework your iteration plan 4. check your project deadline

100 days seems really long; that's around half a year in work time! Why have 100 days on the cards at all?

Absolutely, 100 days is a very long time. If someone turns up a 100-days card then there's something seriously misunderstood or wrong with the user story. If you find that it's the user story that's simply too long, then it's time to break that user story up into smaller, more easily estimatable stories.

Q: What if I'm sure that I know what the customer wants at the beginning of a project? Do I still need to iterate?

Absolutely. Iteration and getting feedback from your customer is important especially when you think you know it all up front. Sometimes it can seem like a complete no-brainer on a simple piece of software, but checking back with the customer is ALWAYS worth it. Even if the customer just tells you you're doing great, and even if you actually do start out with all the right requirements, iteration is still a way to make sure you're on the right track. And, don't forget, the customer can always change their mind.

These descriptions all seem really blurry right now. Don't we need a bit more information before we can call them requirements?

Absolutely. There are lots of gaps in understanding in these descriptions. To fill in those gaps, we need to go back and talk to the customer some more...

The goal is convergence

After a solid round of planning poker, you should not only have estimates for each user story but be confident in those estimates. The goal now is to get rid of as many assumptions as possible, and to converge all of the points on each user story's spread of estimates.

I have a few days left over in my Milestone 1.0. Can't I add in a user story that breaks my day limit just a little bit?

Again, probably not a good idea. If your stories add up to leave you one or two days at the end of the iteration, that's OK.

User story estimates should be smaller

An entire iteration should ideally be around 1 calendar month in duration. Take out weekends and holidays, and that's about 20 working days. If your estimate is 40 days for just one user story, then it won't even fit in one iteration of development unless you have two people working on it! As a rule of thumb, estimates that are longer than 15 days are much less likely to be accurate than estimates below 15 days.

What does an iteration produce

An iteration produces working software A working build also makes a big difference to your team's productivity because you don't have to spend time fixing someone else's code before you can get on with your own tasks Each iteration is a mini-project Each iteration is QUALITY software Iteration length should be at the right tempo for your team

"AND" Rule

Apply the AND rule. Any user story that has an "and" in its title or description can probably be split into two or more smaller user stories.

How early in a project should I start iterating?

As early as you have a piece of software running that you can discuss with your customer. We normally recommend around 20 work days—1 calendar month, per iteration as a rule of thumb—but you could certainly iterate earlier. One- or two-week iterations are not unheard of. If you aren't sure about what a customer means on Day 2, call them. No sense waiting around, guessing about what you should be doing, right?

How did you come up with 190 days when you added two new developers?

At this point this number is a guesstimate. We've guessed that adding two people to build a team of three will mean we can do around 190 days of work in 90 calendar days. There are ways to back up this guess with some evidence using something called "team velocity," but we'll get back to that later on in this chapter.

Software isn't complete until...

its been released

I'm still worried about that burn-down rate being way up, is there anything I can do right now to fix that?

A burn-down rate that's going up is always a cause for concern, but since you're early on, let's wait a bit and see if we catch up.

Standup Meeting

A daily team meeting held to provide a status update to the team members. Very quick- 15 mintues.

Requirements must be:

A great requirement is actually written from your customer's perspective describing what the software is going to do for the customer. Any requirements that your customer doesn't understand are an immediate red flag, since they're not things that the customer could have possibly asked for.

What is a task

A task specifies a piece of development work that needs to be carried out by one developer in order to construct part of a user story. Each task has a title so you can easily refer to it, a rough description that contains details about how the development of that task should be done, and an estimate. Each task has its own estimate and—guess what—the best way to come up with those estimates is by playing planning poker again with your team.

Software development is...

Software development is NOT guesswork. You need to keep the customer in the loop to make sure you're on the right path.

That sucks! So I only have 14 days of actual productive work per iteration if my velocity is 0.7?

0.7 is a conservative estimate for when you have new members of your team coming up to speed and other overheads. As you and your team complete your iterations, you'll keep coming back to that velocity value and updating it to reflect how productive you really are.

0.7 seems to add up to a LOT of lost time. What sorts of activities could take up that sort of time?

0.7 is a safe first guess at a team's velocity. One example is where you are installing a new piece of software, like an IDE or a database (naming no specific manufacturers here, of course). In cases like these two hours of interrupted work can actually mean FOUR hours of lost time when you factor in how long it can take a developer to get back in "the zone" and developing productively. It's also worth bearing in mind that velocity is recalculated at the end of every iteration. So even if 0.7 seems low for your team right now, you'll be able to correct as soon as you have some hard data

So, if your iteration is too long, you must talk to the customer and these are the next steps:

1.) Add an iteration to Milestone 1.0 Explain that the extra work can be done if an additional iteration is added to the plan. That means a longer development schedule, but the customer will get what they want in Milestone 1.0. 2.)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 lost; they are just put on the back burner until the next milestone. 3.) Be transparent about how you came up with your figures It sounds strange, but your customer only has your word that you can't deliver everything they want within the deadline they've given you, so it sometimes helps to explain where you're coming from. If you can, show them the calculations that back up your velocity and how this equates to their needs. And tell your customer you want to deliver them successful software, and that's why you've had to sacrifice some features to give yourself a plan that you are confident that you can deliver on.

How to repriortize to meet deadline

1.) Cut out more FUNCTIONALITY The very first thing you can look at doing to shorten the time to delivering Milestone 1.0 is to cut out some functionality by removing user stories that are not absolutely crucial to the software working. 2.) Ship a milestone build as early as possible Aim to deliver a significant milestone build of your software as early as possible. This keeps your development momentum up by allowing you and your team to focus on a deadline that's not too far off. 3.) Focus on the BASELINE functionality Milestone 1.0 is all about delivering just the functionality that is needed for a working version of the software. Any features beyond that can be scheduled for later milestones.

Dos and Dont's of Milestone 1.0

1.) Do... balance functionality with customer impatience Help the customer to understand what can be done in the time available. Any user stories that don't make it into Milestone 1.0 are not ignored, just postponed until Milestone 2, or 3... 2.) Don't... get caught planning nice-to-haves Milestone 1.0 is about delivering what's needed, and that means a set of functionality that meets the most important needs of the customer. 3.) Don't... worry about length (yet) At this point you're just asking your customer which are the most important user stories. Don't get caught up on how long those user stories will take to develop. You're just trying to understand the customer's priorities.

How to apply velocity correctly:

1.) First, apply your team velocity to each iteration By taking the number of people in your team, multiplied by the number of actual working days in your iteration, multiplied finally by your team's velocity, you can calculate how many days of actual work your team can produce in one iteration: 2. Add your iterations up to get a total milestone estimate Now you should estimate the number of iterations you need for your milestone. Just multiply your days of work per iteration by the number of iterations, and you've got the number of working days you can devote to user stories for your milestone:

Run through this cycle of steps till you reach a consensus:

1.) Talk to the customer First and foremost, get as much information and remove as many assumptions and misunderstandings as possible by talking to your customer. 2.) Play planning poker Play planning poker with each of your user stories to uproot any hidden assumptions. You'll quickly learn how confident you are that you can estimate the work that needs to be done. 3.) Clarify your assumptions Using the results of planning poker, you'll be able to see where your team may have misunderstood the user stories, and where additional clarification is needed. 4.) Come to a consensus Once everyone's estimates are close, agree on a figure for the user story's estimate.

User Story Should not:

1.) be a long essay 2.) use technical terms unfamiliar to the customer 3.) mention specific technologies

User Story Should:

1.) describe one thing that the software needs to do for the customer 2.) be written using language the customer understands 3.) be written by the customer (customer drives them) 4.) be short aim for no more than 3 sentences

Keep iterations short and sweet

30 day iterations are 30 calendar days which is 20 working days. SHORT iterations help you deal with change and keep you and your team motivated and focused.

Formula for days required to get work done

Days of work estimate divided by velocity

How close is a close enough for a consensus estimating?

Deciding when your estimates are close enough for consensus is really up to you. When you feel confident in an estimate, and you're comfortable with the assumptions that have been made, then it's time to write that estimate down on your user story card and move on.

But I'm only a team of one, do I still need to iterate?

Good question, and the answer is yes (starting to detect a theme here?). You might only be a development team of one, but when it comes to your project there are always, at a minimum, two people who have a stake in your software being a success: your customer and you. You still have two perspectives to take into account when making sure your software is on the right path, so iteration is still really helpful even in the smallest of teams.

Some people are just bound to pick nutty numbers. What do I do about them?

Good question. First, look at the trends in that individual's estimates to see if they really are being "nutty," or whether they in fact tend to be right! However, some people really are inclined to just pick extremely high or very low numbers most of the time and get caught up in the game. However, every estimate, particularly ones that are out of whack with the rest of the player's estimates, should come under scrutiny after every round to highlight the assumptions that are driving those estimates. After a few rounds where you start to realize that those wacky estimates are not really backed up by good assumptions, you can either think about removing those people from the table, or just having a quiet word with them about why they always insist on being off in left field.

What happens when my customer comes back with bad news, saying I'm way off on what I'm building. What do I do then?

Great question! When the worst happens and you find that you've deviated badly during an iteration, then you need to bring things back into line over the course of the next couple of iterations of development.

What if you don't have a next iteration? What if you're already on the last iteration, and then a top priority feature comes in from the customer?

If a crucial feature comes in late to your project and you can't fit it into the last iteration, then the first thing to do is explain to the customer why the feature won't fit. Be honest and show them your iteration plan and explain why, with the resources you have, the work threatens your ability to deliver what they need by the due date. The best option, if your customer agrees to it, is to factor the new requirement into another iteration on the end of your project, extending the due date. You could also add more developers, or make everyone work longer hours, but be wary of trying to shoehorn the work in like this. Adding more developers or getting everyone to work longer hours will often blow your budget and rarely if ever results in the performance gains you might expect

Your board's only as VALUABLE as it is ACCURATE

If you want to know where you are on a project, you have to make sure your board reflects reality.

I've done the math and no matter how I cut the user stories up, I just can't deliver what my customer wants when they want me to. What can I do?

It's time to confess, unfortunately. If you really can't build the software that is required in the time that it's 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 at least you were honest with the customer. Another option is to try to beef up your team with new people to try and get more work done quicker. However, adding new people to the team will up the costs considerably, and won't necessarily get you all the advantages that you'd think it might.

Won't adding technical terms and some of my ideas on possible technologies to my user stories make them more useful to me and my team?

No, avoid tech terms or technologies at this point. Keep things in the language of the customer, and just describe what the software needs to do. Remember, the user stories are written from the customer's perspective. The customer has to tell you whether you've gotten the story right, so a bunch of tech terms will just confuse them (and possibly obscure whether your requirements are accurate or not). If you do find that there are some possible technical decisions that you can start to add when writing your user stories, note those ideas down on another set of cards (cross referencing by title). When you get to coding, you can bring those ideas back up to help you at that point, when it's more appropriate.

Should we be thinking about who implements a user story when coming up with our estimates?

No, every player estimates how long they think it will take for them to develop and deliver the software that implements the user story. At estimation time you can't be sure who is going to actually implement a particular user story, so you're trying to get a feel for the capability of anyone on your team to deliver that user story. Of course, if one particular user story is perfect for one particular person's skills, then they are likely to estimate it quite low. But this low estimate is balanced by the rest of your team, who should each assume that they are individually going to implement that user story. In the end, the goal is to come up with an estimate that states "We as a team are all confident that this is how long it will take any one of us to develop this user story."

Should we be using a specific format for writing user stories?

No. Right now you're just grabbing and sorting out the ideas that your customer has and trying to get those ideas into some sort of manageable order.

What's the difference between a milestone and a version?

Not much. In fact you could call your first milestone "Version 1" if you like. The big difference between a milestone and a version is that a milestone marks a point at which you deliver signficant software and get paid by your customer, whereas a version is more of a simple descriptive term that is used to identify a particular release of your software. The difference is really quite subtle, but the simple way to understand it is that "Version" is a label and doesn't mean anything more, whereas "Milestone" means you deliver signficant functionality and you get paid. It could be that Version 1.0 coincides with Milestone 1.0, but equally Milestone 1.0 could be Version 0.1, 0.2 or any other label you pick.

Is there a maximum team size that I should never go over?

Not really. Depending on your experience you may find that you can happily handle a 20-person team, but that things become impossible when you hit 21. Alternatively you might find that any more than three developers, and you start to see a dip in productivity. The best approach is to monitor performance closely and make amendments based on your observations.

Most projects have two constraints

On time and on budget

Big Board

Once you know exactly what you're building, it's time to set up your software development dashboard for Iteration 1 of development. Your dashboard is actually just a big board on the wall of your office that you can use to keep tabs on what work is in the pipeline, what's in progress, and what's done.

Why allocate tasks just from the first user story. Why not take one task from each user story?

One good reason is so that so that you don't wind up with five stories in a half-done state, and instead can wrap up a user story and move on to the next. If you've got one story your other stories depend on, you may want to get all that first story's tasks done at once. However, if your stories are independent of each other, you may work on tasks from multiple stories all at the same time.

How to come up with individual estimates:

Play Planning Poker: 1.) Place a user story in the middle of the table. This focuses everyones attention on the current user story. 2.) Everyone is given a deck of 13 cards. Each card has an estimate written on one side. This represents the working days to complete the user story 3.) Everyone picks an estimate for the user story and places the corresponding card face down on the table. You pick the card that you think is a reasonable estimate for the user story. Don't discuss that estimate with anyone else, though. 4.) Everyone then turns over their cards at exactly the same time. Each player at the table shows their hand, which gives their honest estimate for the user story. 5.) The dealer marks down the spread across each of the estimates.Whoever is running the game notes the spread across each of the estimates that are on the cards. Then you do a little analysis:

I have a number of assumptions, but I still feel confident in my estimate. Is that okay

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.

Two particularly useful techniques that help you understand the customer are role playing and observation.

Role playing: If your customer is finding it hard to visualize how they need their software to work, act it out. You pretend to be the software and your customer attempts to instruct you in what they would like you to do. Then write down each thing the software needs to do on one of your requirement cards. Observation: Sometimes the best way to understand how people will work with your software is to watch them, and figure out where your software will fit in. Nothing beats firsthand evidence, and observation can really help to bring out constraints and details that might have been missed in bluesky brainstorming or even in role playing. Also, try to observe the same interactions more than once with multiple observers so you don't just gain one person's impression of an event.

Process

Sequence of steps

What happens when I discover a big missing task?

Sometimes—hopefully not too often—you'll come across a task that just breaks your user story estimate completely. You might have forgotten something important when first coming up with the user story estimates, and suddenly the devil in the details rears its ugly head, and you have a more accurate, task-based estimate that completely blows your user story estimate out of the water. When this happens you can really only do one thing, and that's adjust your iteration. To keep your iteration within 20 working days, you can postpone that large task (and user story) until the next iteration, reshuffling the rest of your iterations accordingly. To avoid these problem, you could break your user stories into tasks earlier. For instance, you might break up your user stories into tasks when you initially plan your iterations, always relying on your task estimates over your original user story estimates as you balance out your iterations to 20 working days each.

What about the question-mark card? What does that mean?

That you simply don't feel that you have enough information to estimate this user story. Either you've misunderstood something, or your assumptions are so big that you don't have any confidence that any estimate you place down on the table could be right.

So what exactly is my software's baseline functionality?

The baseline functionality of your software is the smallest set of features that it needs to have in order for it to be at all useful to your customer and their users. Think about a word processing application. Its core functionality is to let you load, edit, and save text to a file. Anything else is beyond core functionality, no matter how useful those features are. Without the ability to load, edit, and save a document with text in it, a word processor simply is not useful. That's the rule of thumb: If you can get by without a feature, then it isn't really baseline functionality, and it's probably a good candidate for pushing out to a later milestone than Milestone 1.0 if you don't have time to get everything done.

Milestonee 1.0

The 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)

Analysis of Planning Poker

The larger the difference between the estimates, the less confident you are in the estimate, and the more assumptions you need to root out. Large spreads can be a misunderstanding

What if I get to the end of an iteration, and I don't have anything to show my customer?

The only way you should end up at the end of an iteration and not have something to show the customer is if no user stories were completed during the iteration. If you've managed to do this, then your project is out of control and you need to get things back on track as quickly as possible.

But 190 days of work is less than the 190 days that our three-developer team can produce, shouldn't we add some more features with the customer?

The overall estimate doesn't actually have to be exactly 189 days. Given that we're dealing with estimates anyway, which are rarely 100% accurate, and that we tend to be slightly optimistic in our estimates then 165 days is close enough to the 189-day mark to be reasonably confident of delivering in that time.

Iteration is more than a process

The right software development process for YOU is one that helps YOU develop and deliver great software, on time and on budget.

Big Bang Approach

Waterfall method, you met with the customer once and you build what you think he needs. The risk with that approach is you think you're building what the customer wants with no real feedback until you think you're finished.

What's the "Title" field on my user stories for? Doesn't my description field have all the information I need?

The title field is just a handy way to refer to a user story. It also gives everyone on the team the same handy way to refer to a story, so you don't have one developer talking about "Pay by PayPal," another saying, "Pay with credit card," and find out they mean the same thing later on (after they've both done needless work).

This seems like a lot of requirements work up front at the beginning of the project. What about when things change?

The work you've done so far is just your first attempt at gathering requirements at the beginning of your project. You'll continue to refine and capture new requirements throughout your project, feeding those requirements where necessary into your project's iterations.

Talk to your customer to get MORE information

There are always gaps in your understanding of what your software is supposed to do, especially early in your project. Each time you have more questions, or start to make assumptions, you need to go back and talk with the customer to get answers to your questions.

How do I figure out who to assign a task to?

There are no hard-and-fast rules about who to give a task to, but it's best to just apply some common sense. Figure out who would be most productive or—if you have the time, will learn most from a particular task by looking at their own expertise—and then allocate the task to the best-suited developer, or the one who will gain the most, that's not already busy.

Programmers think in utopian days

They're going to give you a better-than-best-case estimate. Developers think in REAL-WORLD days...

Burn Down Chart

This graph monitors how quickly you and your team are completing your work, measured in days on the vertical axis. This chart then plots how quickly you tick off your work remaining against the number of days left in your iteration. You want to be below the line of the ideal.

What happens when the customer comes up with new requirements and you can't fit all the extra work into your current iteration?

This is when customer priority comes into play. Your customer needs to make a call as to what really needs to be done for this iteration of development. The work that cannot be done then needs to be postponed until the next iteration. We'll talk a lot more about iteration in the next several chapters.

OK, without squeezing my last user story in I end up coming under my work-day limit by a LONG way. I have 15 days free at the end of Milestone 1.0! Is there anything I can do about that?

To fit a story into that space, try and come up with two simpler stories and fit one of those into Milestone 1.0 instead.

Your daily standup meetings should:

Track your progress. Get everyone's input about how things are going. Update your burn-down rate. It's a new day so you need to update your burndown rate to see how things are going. Update tasks. If a task is completed then it's time to move it over into the Completed area and check those days off of your burn-down rate. Talk about what happened yesterday and what's going to happen today. Bring up any successes that happened since yesterday's standup meeting and make sure everyone knows what they're doing today. Bring up any issues. The standup meeting is not a place to be shy, so encourage everyone to bring up any problems they've encountered so that you all as a team can start to fix those problems. Last between 5 and 15 minutes. Keep things brief and focused on the short-term tasks at hand. A daily standup meeting should keep everyone motivated, keep your board up-to-date, and highlight any problems early.

It's always better to deliver some of the features working perfectly than all of the features that don't work properly. T/F

True

Your estimates are your PROMISE to your customer about how long it will take you and your team to DELIVER.

True

RULES OF THUMB

Try to double-up tasks that are related to each other, or at least focus on roughly the same area of your software. The less thought involved in moving from one task to another, the faster that switch will be. Try not to double-up on tasks that have large estimates. It's not only difficult to stay focused on a long task, but you will be more confident estimating the work involved the shorter the task is.

User stories define:

User stories define the WHAT of your project... estimates define the WHEN

what is velocity?

Velocity is a percentage: given X number of days, how much of that time is productive work? Normal starting velocity is 0.7. Best of all, though, you can apply velocity to your amount of work, and get a realistic estimate of how long that work will actually take.

Wouldn't it just be better to spend more time getting to know what the customer really wants, really getting the requirements down tight, than always letting the customer change their mind midstream?

You'd think so, but actually this is a recipe for disaster. In the bad old days, developers used to spend ages at the beginning of a project trying to make sure they got all the customer's requirements down completely before a single line of code or design decision was made. Unfortunately, this approach still failed. Even if you think that you completely understand what the customer needs at the beginning, the customer often doesn't understand. So they're figuring out what they want as much as you are. You need a way of helping your team and your customer grow their understanding of their software as you build it, and you can't do that with a Big Bang, up-front requirements approach that expects everything to be cast in stone from day one.

Aren't these requirements just user stories?

You're not far off, but at the moment they are just ideas. In just a few more pages we'll be developing them further into full-fledged user stories. At the moment it's just useful to write these ideas down somewhere.

How much of this process should my customer actually see?

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.

Project Estimate:

Your project estimate is the sum of the estimates for your user stories

How big should a task estimate be?

Your task estimates should ideally be between 1/2 and 5 days in length. A shorter task, measured in hours, is too small a task. A task that is longer than five days spreads across more than one working week, and that gives the developer working on the task too much time to lose focus.

Task estimates add confidence to user story estimates

Your user story estimates kept you in the right ballpark when you were planning your iterations, but tasks really add another level of detail specific to the actual coding you'll do for a user story.

User Story

a story about how their users interact with the software you're building.