[ HF Software Dev ] Chap9 : Ending an iteration - It’s all coming together...

Preface : 
You’re almost finished! The team’s been working hard, and things are wrapping up. Your tasks and user stories are complete, but what’s the best way to spend that extra day you ended up with? Where does user testing fit in? Can you squeeze in one more round of refactoring and redesign? And there sure are a lot of lingering bugs...when do those get fixed? It’s all part of the end of an iteration... so let’s get started on getting finished. 

Your iteration is just about complete... : 
You’ve made it! You’ve successfully put your process in place: the stories have piled up in the Completed section of your board, and everyone’s 
ready for a little breather. Before people head out for the weekend, though, let’s do a quick status check : 
 
Suppose all your hard work has resulted in a day or two to spare at the end of your iteration. What else could you do if you had more time? 

...but there’s lots left you could do : 
There are always more things you can do on a project. One benefit of iterative development is that you get a chance to step back and think about what you’ve just built every month or so 
 

System testing MUST be done... : 
Your system has to work, and that means using the system. So you’ve got to either have a dedicated end-to-end system testing period, or you actually let the real users work on the system (even if it’s on a beta release). No matter which route you go, you’ve got to test the system in a situation that’s as close to real-world as you can manage. That’s called system testing, and it’s all about reality, and the system as a whole, rather than all its individual parts. 
Key Point: 

System testing exercises the FUNCTIONALITY of the system from front to back in real-world, black-box scenarios.

 

...but WHO does system testing? 
You should try your best to have a different set of people doing your system testing. It’s not that developers aren’t really bright people; it’s just that dedicated testers bring a testing mentality to your project. 
- Developer testing 

Developers come preloaded with lots of knowledge about the system and how things work underneath. No matter how hard they try, it’s really tough for developers to put themselves in the shoes of end users when they use the system. Once you’ve seen the guts, you just can’t go back.

- Tester testing 

Testers can often bring a fresh perspective to the project. They approach the system with a fundamentally different view. They’re trying to find bugs. They don’t care how slick your multithreaded, templated, massively parallel configuration file parser is. They just want the system to work.

Good system testing requires TWO iteration cycles : 
Iterations help your team stay focused, deal with just a manageable amount of user stories, and keep you from getting too far ahead without built-in checkpoints with your customer.But you need all the same things for good system testing. So what if you had two cycles of iterations going on? 
This assumes you’ve got two separate teams: one working on code, the other handling system testing. But the same principles apply if your second team is other developers. 
 

More iterations means more problems : 
System testing works best with two separate teams, working two separate iteration cycles. But with more iterations comes more trouble—problems that aren’t easy to solve. Running two cycles of iterations means you’ve got to deal with : 
- LOTS more communication 
Not only do you have inter-team communication issues, but you’ve got two teams trying to work together. The testing team will have questions on an iteration, and the development team wants to get on to the next story, not field queries. One way to help this is to bring a representative from the test team into your standup meetings as an observer. He’ll get a chance to hear what’s going on each day and get to see the any notes or red stickies on the board as the iteration progresses. (It’s not a time to prioritize bugs or ask questions about how to run things.) 

- Testing in a FIXED iteration length 
If you’re keeping your two iteration cycles in sync—and that’s the best way to keep the testing team caught up— you’re forcing testing to fit into a length that might not be ideal. To help give the test team a voice in iterations, you can have them provide you a testing estimate for stories you’re planning on including in your iteration. It might give you some insight into where the testing team might get hung up or need some help to get through a tough iteration. 

- Fixing bugs while you keep working 
The development team will start getting bug reports on their second iteration about the time they’re getting into the third iteration! And then you have to figure out if the bug’s important enough to fix right away, roll into the current iteration, or put off for later. The straightforward approach is to treat a bug like any other story. Prioritize it against everything else and bump lower-priority stories if you need to in order to get it done sooner. 
Another approach is to carve off a portion of time every week that you’ll dedicate to bug fixes. Take this off of the available hours when you do your iteration planning, so you don’t need to worry about it affecting your velocity. For example, you could have everyone spend one day a week on bug fixes—about 20% of their time. 

- Writing tests for a moving target 
Functionality in user stories—even if it’s agreed upon by the customer—can change. So lots of times, tests and effort are being put into something that changes 30 days later. That’s a source of a lot of irritation and frustration for people working on tests. There’s not much you can do here except communicate. Communicate as soon as you think something might change. 
Key Point : 

The key to most problems you’ll run into in software development is COMMUNICATION. When in doubt, TALK to your team, other teams, and your customer.

The life (and death) of a bug : 
Eventually, your testers are going to find a bug. In fact, they’ll probably find a lot of them. So what happens then? Do you just fix the bug, and not worry about it? Do you write it down? What really happens to bugs? 
 

Bugs belong in a bug tracker : 
The most important thing about dealing with bugs on a software project is making sure they get recorded and tracked. For the most part it doesn’t matter which bug tracking software you use; there are free ones like Bugzilla and Mantis or commercial ones like TestTrackPro and ClearQuest. The main thing is to make sure the whole team knows how to use whatever piece of software you choose. You should also use your tracker for more than just writing down the bug, too. Make sure you : 
1. Record and communicate priorities 

Bug trackers can record priority and severity information for bugs. One way to work this in with your board is to pick a priority level—say priority 1, for example—and all bugs of that priority level get turned into stories and prioritized with everything else for the next iteration. Any bugs below priority 1 stay where they are until you’re out of priority 1 bugs.

2. Keep track of everything 

Bug trackers can record a history of discussion, tests, code changes, verification, and decisions about a bug. By tracking everything, your entire team knows what’s going on with a bug, how to test it, or what the original developer thought they did to fix it.

3. Generate metrics 

Bug trackers can give you a great insight into what’s really going on with your project. What’s your new-bug submission rate? And is it going up or down? Do a significant number of bugs seem to come from the same area in the code? How many bugs are left to be fixed? What’s their priority? Some teams look for a zero-bug-bounce before even discussing a production release; that means all of the outstanding bugs are fixed (bug count at zero) before a release.

Anatomy of a bug report : 
As a general rule of thumb, the more information you can provide in a bug report, the better. Even if you work on a bug and don’t fix it, you should record what you’ve done, and any ideas about what else might need to be done. You—or another developer—might save hours by referring to that information when you come back to that bug later. A good bug report should have : 
* Summary 

Describe your bug in a sentence or so. You should be able to read the summary and have a clear understanding of what the problem is.

* Steps to reproduce 

Describe how you got this bug to happen. You might not always know the exact steps to reproduce it, but list everything you think might have contributed.

* What you expected to happen and what really did happen 

Explain what you thought was going to happen, and then what actually did happen. This is particularly helpful in finding story or requirement problems where a user expected something that the developers didn’t know about.

* Version, platform, and location information 

What version of the software were you using? If your application is web-based, what URL were you hitting? If the app’s installed on your machine, what kind of installation was it? A test build? A build you compiled yourself from the source code?

* Severity and priority 

How bad is the impact of this bug? Does it crash the system? Is there data corruption? Or is it just annoying? How important is it that the bug gets fixed? Severity and priority are often two different things. It’s possible that something is severe (kills a user’s session or crashes the application) but happens in such a contrived situation (like the user has to have a particular antivirus program installed, be running as a non-Administrator user, and have their network die while downloading a file) that it’s a low-priority fix.

Time for the iteration review : 
It’s here: the end of your iteration. You’re remaining work is at zero, you’ve hit the last day of the iteration, and it’s time to start getting ready for the next iteration. But, before you prioritize your next stories, remember : it’s not just software we’re developing iteratively. You should develop and define your process iteratively, too. At the end of each iteration, take some time to do an iteration review with your team. Everyone has to live with this process so make sure you incorporate their opinions. 
1. Prepare ahead of time 

An iteration review is a chance for the team to give you their input on how the iteration went, not a time for you to lecture. However, it’s important to
keep the review focused, too. Bring a list of things you want to make sure get discussed and introduce them when things start wandering off.

2. Be forward-looking 

It’s OK if the last iteration was tragic or if one if the developers consistently introduced bugs, as long as the team has a way to address it in the next iteration. People need to vent sometimes, but don’t let iteration reviews turn into whining sessions; it demoralizes everyone in the end.

3. Calculate your metrics 

Know what your velocity and coverage were for the iteration that just completed. In general, it’s best to add up all of the task estimates and
divide by the theoretical person-days in your iteration to get your velocity. Whether or not you reveal the actual number during the review is up to you (sometimes it helps to not give the actual number just yet so as not to bias any upcoming estimates), but you should convey whether the team’s velocity went up or down.

4. Have a standard set of questions to review 

Have a set of questions you go through at the end of each iteration. The set of questions can change if someone would like to add something or a question really doesn’t make sense for your team. Having recurring discussion topics means people will expect the questions and prepare (even unconsciously during an iteration) for the review.

A GENERAL priority list for getting EXTRA things done... : 
You’ve got to figure out what’s best for your project, but here are some general things you can look at if you’ve got extra time in your iteration. 
- Fix bugs 

Obviously this depends on what your bug backlog looks like. Remember to prioritize bugs with the customer, too. There might be some bugs that are vital to the customer, and others they just don’t care that much about.

- Pull in stories that are on deck for next iteration 

Since the customer has prioritized more stories than typically fit in an iteration, you can try pulling in a story from the next iteration and get working on it now. Be careful doing this, though, as the customer’s priorities or ideas for the story may have changed during your iteration. It’s also good to make sure you know whether or not the test team has time to test any extra stories you pull in.

- Prototype solutions for the next iteration 

If you have an idea about what’s likely coming in the next iteration, you might want to take advantage of an extra day or two to start looking ahead. You could try writing some prototype code or testing technologies or libraries you might want to include. You probably won’t commit this code into the repository, but you can get some early experience with things you plan on rolling into the next iteration. It will almost certainly help your estimates when you get back to planning poker.

- Training or learning time 

This could be for your team or for your users. Maybe the team goes to a local users group’s session during work hours. Get a speaker or technology
demo setup. Run a team-building exercise like sailing or paintball. Care and feeding of your team is an important part of a successful project.

Tools for your Software Development Toolbox :