[ HF Software Dev ] Chap10 : The next iteration - If it isn't broken... you still better fix it

Preface :
Your iteration went great, and you’re delivering working software on time. Time for the next iteration? No problem, right? Unfortunately, not right at all. Software development is all about change, and moving to your next iteration is no exception. In this chapter you’ll learn how to prepare for the nextiteration. You’ve got to rebuild your board and adjust your stories and expecations based on what the customer wants NOW, not a month ago.

What we can do for Next iteration? 
When you come to the end of an iteration, you should have a buildable piece of software. But complete software is more than just code. It’s also...

- Completing your iteration’s work 

You’re getting paid to get a certain amount of work done. No matter how clever your code, you’ve got to complete tasks to be successful.

- Passing all your tests

Unit tests, system tests, black- and white-box tests...if your system doesn’t pass your tests, it’s not working.

- Satisfying your customer

Software that does what it’s supposed to do, in the time you promised it, usually makes customers pretty excited. And in lots of cases, it means you’ve got another iteration’s worth of work.

You need to plan for the next iteration :
Before diving into the next iteration, there are several things that all play a crucial part in getting ready. Here are the key things to pay attention to:

- Additional user stories

The customer will reprioritize user stories, and probably add some new ones, too.

- Velocity

How fast you and your team got through the work for Iteration 1 affects your anticipated velocity for Iteration 2.

- Burn Down

You need to come up with a new project board for the next iteration, including a fresh burn-down rate, and a new velocity calculation.

- “Next” user stories

If you pushed any user stories out of the last iteration, or the customer reprioritized, that means you’ve already got some leftover user stories and tasks to think about.

- Bugs

Bugs that haven’t already been worked into your development have to be considered; some will end up as tasks in the next iteration.

You need to revise your story and task estimates and your team’s velocity :
When originally planning Orion’s Orbits, you and your team came up with estimates for each of the user stories for Version 1.0, and then the tasks associated with each of those user stories. Now that it’s time to kick off another iteration, you have a lot more knowledge about how things will work. So it’s time to revisit those estimates for the remaining user stories and tasks.

Also, when you originally calculated how much work you could complete in the first iteration, you didn’t know how fast your team could develop software and complete their tasks. You probably used an initial value of something like 0.7 for your team’s velocity. But that was just a rough guess...now, you and your team have completed an iteration. That means you’ve got hard data you can use for recalculating velocity, and getting a more accurate figure.

Remember, your estimates and your velocity are about providing confident statements to your customer about what can be done, and when it will be done. You should revise both your estimates and your velocity at every iteration.
Crux :

Recalculate your estimates and velocity at each iteration, applying the things you learned from the previous iteration.

1. Calculate your new velocity
Take your team’s performance from the previous iteration and calculate a new value for this iteration’s velocity :


2. Calculate the work days you have available
Now that you have your team’s velocity, you can calculate the maximum number of work days that you can fit into this iteration :


3. Fill up the board with new work
You know how many work days you’ve got, so all that’s left is to take the candidate user stories and bugs, as well as stories left over the last iteration, and add them to your board—make sure you have a manageable work load :


Velocity accounts for... the REAL WORLD :
Velocity is a key part of planning out your next iteration. You’re looking for a value that corresponds to how fast your team actually works, in reality, based on how they’ve worked in the past. This is why you only care about what was done, and how long it took to get done. That’s the
key information that tells you what to expect in the next iteration.


And it’s STILL about the customer :
Let’s say you’ve calculated your new velocity. You collected bugs and put them all in a bug tracker. You waded through all the piles of unfinished and delayed tasks and stories, and had the customer reprioritize those along with stories planned for the next iteration. You’ve got your board ready to go. You still have to go back and get your customer’s approval on your overall plan. And that’s when things can go really wrong...

In this case, you are required to integrate some codes from other company for your customer. That means the original code for next iteration may not be available and so as the user stories and estimation. Software is still about CHANGE. Sometimes the customer is going to come up with a big change at the last minute. Or your best plans break down when your star programmer takes a new job...

But even though what you’re working on has changed, the mechanics of planning haven’t. You have a new velocity, and you know how many days of work your team has available. So you simply need to build new user stories, reprioritize, and replan :

Someone else’s software is STILL just software :
Even though the Mercury Meals library is not code you have written, you still treat the work necessary to integrate the code into Orion’s Orbits as you would do for software development activities. You’ll need to tackle all the same basic activities :
- User stories

Every change to the software is motivated by and written down as a user story. In this case, your story card will be a description of how the Mercury Meals code is used by the Orion’s Orbit system to achieve some particular piece of functionality.

- Estimates

Every user story needs an estimate. So each of the user stories that the Mercury Meals code library plays a part in has to be estimated. How much time will it take to build that functionality, including time spent integrating the Mercury Meals code?

- Priorities

The final piece of the puzzle is, of course, priorities. Each of the user stories associated with the Mercury Meals code needs to have an associated priority from your customer so that you can plan out the work for the next iteration, in the order that your customer wants it done.

Once again, you’ve got to get customer approval once everything’s planned out. And this time, there aren’t any surprises... (No news is good news)

Integrating 3'rd party source code :
When it comes to code that someone else has written, it’s all about trust, and the real lesson here is to trust no one when it comes to code. Unless you’ve seen a piece of code running, or run your own tests against it, someone else’s code could be a ticking time bomb that’s just waiting to explode—right when you need it the most.

When you take on code from a third party, you are relying on that code to work. It’s no good complaining that it doesn’t work if you never tried to use it, and until you have seen it running, it’s best to assume that third-party code doesn’t really work at all.


A third party is not you. That might sound a little obvious, but it’s really important when you’re tempted to assume that just because you use a great testing and development process, everyone else does, too.


You with your process :
It’s not a perfect world. When your code—or someone else’s code you depend on—isn’t working, and your customer is breathing down your neck, it’s easy to panic or catch the next flight to a non-extradition country. But that’s when a good process can be your best friend :

* We need to get a good and get back to it! estimate of how long it will take to fix this code.
* So let’s update the burn and get back to it!
* Once we get the third-party stuff working, we’re done and we can do that demo...

Dealing with code that doesn’t work is part of software development! In Chapter 11, you’ll see how your process can handle the heat.

Tools for your Software Development Toolbox :