Progressive Development : project management

Motley says: "Features sell a product. When in doubt, add more features!"

James Waletzky — Tue, 08 Jul 2008 16:55:00 GMT

Summary

Motley: Features sell a product. When in doubt, add more features!

Maven: These days, software is less about features and more about reliability, fit 'n finish, performance, and usability. Use the Kano model to help you focus on the right scenarios for the user.

______________________________

[Context: Motley is struggling with a common project management problem]

Motley: I am wondering how we are ever going to make any money on this product. We had to make so many cuts to make it to market in a reasonable time that the product is not all that useful, in my opinion. We need more features, and we need them quickly.

Maven: Do you think it's just features that make a product successful and sell lots of copies?

Motley: Well, pretty much. If the software doesn't do what you need it to do, why would you bother buying it? Features trump everything else. For a v1, we should even consider shipping sooner with a few more bugs to get a few more features in.

Maven: Hmmm… you were telling me the other day that you have an iPod Touch, right?

Motley: Why are you wasting my time here? Yes, I have an iPod Touch. Get to the point.

Maven: One more question: why do you have an iPod Touch vs. a Creative Labs Player vs. a Zune? The iPod costs significantly more doesn't it? And don't the other players typically have more memory for the same money, and perhaps include FM tuners?

Motley: That was three questions, wise guy. I chose the iPod Touch after playing with it for a while. It does what I need it to do, it's reliable, and it's extremely well refined and polished. I could flick the list views and pan around for hours. I love watching the acceleration of the list view as you start to flick and slow down as "friction" takes over. They really did a nice job with the interface. I had to have it. It's a really fun device to use.

Maven: So it's more than just features that attracted you to that particular model?

Motley: Well, in this case, yes. I looked at the other MP3 players out there, but I wasn't impressed. They had the same features, but the iPod Touch was just, well, fun. Additionally, one of the other players that shall go unnamed crashed within just a few minutes of use. I was not impressed.

Maven: Does the iPod Touch do everything you want it to do?

Motley: Not necessarily. It would be great if it had a built in GPS, for example, so I could hop on a wi-fi network and get directions from where I am. An FM tuner would be nice for those nights I go to the races (they broadcast the commentary over FM). But seriously, I have to get some work done. Why are you bothering me about all this?

Maven: Let's go back to the software you are working on - you were saying we need more features and should even ship with slightly lower quality to get features in. Does that equate back to your iPod Touch experience?

Motley: Well, errrrr, ummmm…

Maven: That's what I thought. A decade ago, when there was little competition for many software products on the market, features won the war. End users actually put up with an operating system like Windows 95 that blue screened every other day when it was released. It was the best thing out there and the reliability issues were tolerated. Times have changed. Users expect software to "just work". They want it to solve their problems their way with a minimum of fuss. If it meets the majority of their scenarios and does it well, users are generally happy. These days there are always other options if a product does not meet their needs.

Motley: You did mention "their way" above, though. In order to do things their way, you need to make it as configurable as possible and including knobs and buttons allowing them to customize their experience. That takes time to build.

Maven: I would actually argue that too many knobs to twist, turn and pull just ends up confusing the user creating a frustrating experience. Look at the iPod Touch - two buttons. Compare the browser on the iPod Touch to something like Internet Explorer on the desktop - very few configurability options. But, users are happy. In fact, they are ecstatic about the device. It satisfies 80% of the core user scenarios. It may not keep the power users happy, but there are other options out there, including third party software updates that could potentially add some of the knobs and buttons they need.

Motley: There is still a minimum feature set we would need to be successful.

Maven: No argument there. However, that feature set is usually not as large you think it is. Nail the top priority user scenarios extremely well and you will likely be successful.

Motley: Easier said than done.

Maven: Sometimes. You need to really understand the user in order to make good decisions. Here are a few other keys to success:

Reliability: The user's first experience with the product should be positive. It should "just work". It should be working out-of-the-box within a few minutes. Spend more time during development ensuring it installs easily and doesn't crash vs. adding features. What features are there must be solid.
Fit 'n Finish: Were the gravity and friction capabilities on the iPod Touch really necessary for a decent user experience? No. Do they set the device apart from competitors? Yes. Do they make the device fun to use? Absolutely. Do they set the bar for interfaces on mobile devices? You bet. Nice icons, nice graphics, and little effects add up to a really positive experience with the device when combined with the other criteria listed here.
Performance: Waiting sucks. Apple put the right hardware in the iPod Touch to ensure performance would not suffer. I am sure they spent a lot of time tuning the experience to make it snappy. Users will no longer accept sluggish software. Performance actually is a feature.
Usability: The user interface must be incredibly intuitive such that you do not even need a user's manual. The user should be able to pick up the device and be productive within minutes. An understanding of human psychology is a requirement when developing a good interface.

As another example, how many features of Microsoft Word do you use?

Motley: Out of the 10000? Probably 20.

Maven: Exactly. A few extremely polished features will likely satisfy 80% of your users (see the Pareto Principle, or 80-20 rule). Spend time making an incredible experience for those core features, and add features once the polish is in place. Aim to delight the user.

Motley: Delight the user? That sounds a little "foo-foo" to me. What is "delight the user" supposed to mean?

Maven: Think about the Kano model, which comes from Six Sigma. A diagram illustrating the concept is shown below:

Pasted from <http://www.isixsigma.com/library/content/c030630a.asp>

The lower curve represents the basic needs of the user that must be present in the product for it to stand a chance to be successful. With the iPod Touch example, it better play MP3 files. That is a basic need that the device must fulfill, and if it didn't, it wouldn't sell, at least not as an MP3 player. These features likely won't set you apart from the competition either.

The middle curve represents those features or criteria that you can never have enough of. With the iPod Touch example, more memory, faster performance and better sound quality are always welcomed and can set the product apart from the competition.

The upper curve provides the greatest opportunity to beat competitors, and are those things that truly "delight" the user. With the iPod Touch example, the polished user interface, the flick and pan operations, the automatic playlists, etc. help set it apart from other players and make customers say: "Wow, this is a cool device!" Often these types of "features" are unexpected, but very welcome.

Motley: Interesting model. You are saying that we must met the basic needs, consider performance characteristics, but to really set ourselves apart, we need to consider those things that delight the user. This typically revolves around ideas that really catch the user's attention, and are often the result of polishing existing user experience paradigms and features.

Maven: Exactly. Although polish does not always equate to delighters, it does contribute to a solid user experience - moreso than the addition of several more half-baked features.

______________________________

Maven's Pointer: Although I (James) work for Microsoft, I will gladly give another company kudos for a job well done if it is warranted. I do own an iPod Touch and think it's a fabulous device that other MP3 players cannot keep up with. I have been extremely happy with my purchase, even though I could have gotten a significant discount (relative to other players) on one unnamed player. "It just works" really matters to me - the device and/or software needs to be polished, usable, reliable, performant (is that really a word?), and just do what I need it to do. That's not to say Microsoft doesn't make some fabulous products as well, such as OneNote, Money and Vista (yes, I am happy with Vista). Apple does a set a great example, however, when it comes to building software and devices that consumers love.

Maven's Double Pointer Indirection: There is more to Kano analysis and mentioned here. There is guidance available in some of the resources below on how to ask user positive and negative questions and plotting them on a 2-D table, to determine whether ideas are delighters, performers, or basics.

Maven's Resources:

http://www.isixsigma.com/library/content/c030630a.asp
http://learnsigma.com/kano-model/
George et. al, The Lean Six Sigma Pocket Toolbook: A Quick Reference Guide to 100 Tools for Improving Quality and Speed, McGraw-Hill, ISBN: 0071441190, August 2004.

Motley says: "Milestones are useless for agile development"

James Waletzky — Tue, 24 Jun 2008 17:55:00 GMT

Summary

Motley: Milestones are useless for agile development. Our feature team can ship at the end of every iteration, so milestones have no value for us.

Maven: Milestones provide a synchronization point across a set of features, helping to ensure the overall product is of high quality. Every milestone has a set of exit criteria that the integrated product must satisfy before moving on.

______________________________

[Context: Motley is analyzing his team's upcoming deliverables and is questioning some of the Cynthesis Software development process]

Motley: Overhead, overhead, overhead. Why is the project manager making our team go through all the hassle of hitting a milestone when we are doing iterative development anyway? We have mini-milestones every time we finish an iteration. We produce a shippable piece of functionality that is ready to go. Milestones are useless for us.

Maven: Actually, milestones have use even in an agile world. You are not the only team contributing functionality to the release, right? There are other teams building features?

Motley: Yeah, so? Some of the other teams are doing agile as well so they likely have the same questions as we do. For the others not doing agile, well, they need to wise up and get with the program.

Maven: It's not so easy to change a company, as we discussed in previous conversations on change management. At some point you need to bring all the feature teams together and make sure everyone is synchronized. That's one of the primary purposes of a milestone. It is a checkpoint that all teams have in common with a set of exit criteria. A milestone brings everyone together to ensure all teams can integrate their features and come together to create a product. Milestones may not be technically necessary if there is one small team developing a release. You can ship at the end of every iteration, at least in theory. However, when many teams are involved in creating a large product, you need to periodically bring everyone together.

Motley: Milestones just seem too process-heavy. Why not just sync-up on an as-needed basis?

Maven: Don't forget - milestones also have use to people outside the company.

Motley: Why should anyone outside our development group care about our internal milestones? Perhaps your girlfriend needs to know so she can expect you to work some overtime around the end of a milestone, but other than that, I can't think of any reason.

Maven: With any significantly-sized product, Cynthesis typically ships technical previews, does integrated product demos for customers, and ships beta releases. Typically these interim releases prior to ship align with milestones to ensure product quality is high. Because each small feature team may have their own iteration schedule with their sprints, the milestones provide that date where sprints can align.

Motley: Fine. I can accept all that. It still seems process heavy though. You mentioned the phrase "exit criteria". That phrase has "formal process" stamped all over it. Pepto Bismol is my exit criteria after eating bad seafood.

Maven: Ah, dude, that really wasn't necessary.

Motley: I know, but potty humor is always fun anyway <laugh>.

Maven: Back to business. Yes, "exit criteria" is one of the more formal-sounding software engineering phrases, but it does have use. At the end of any given milestone there is typically a checklist of quality criteria that each team and the overall product has to satisfy before the milestone is considered done. Think of it as a team-wide definition of that ever-so-important definition of "done".

Motley: Ah, so it's a fancy phrase meaning that once we put all the pieces together that they all work well together. That would include overall performance, end-to-end integrated scenario testing, stress testing over time, lack of cross-product memory leaks, general usability and consistency across features, consistency of documentation, how it works with the rest of the system, and other general product health issues.

Maven: Exactly! We put all the pieces of the puzzle together and hopefully it produces a beautiful picture. Without that checkpoint you could ship a product with puzzle pieces that don't match creating a jumbled mess.

Motley: I see. Makes sense. One thing that I would encourage the project managers to do, however, is not make those exit criteria too strict and that we focus on the right things.

Maven: That's a very astute observation, Mot. I worked in one company where the exit criteria list was pages and pages long. After about the first third in priority order, the rest just created needless overhead and diminishing returns. It felt like the project managers were micromanaging the feature teams. Instead of speeding up the development process, it slowed everybody down, in my opinion.

Motley: Ouch. I guess we should consider ourselves lucky here at Cynthesis. I can put up with a reasonable list of exit criteria, but you don't want to know what I do when someone tries to micromanage me.

Maven: Imagine nag nails for every little thing like high priority bugs you haven't updated in the bug database for a few hours, or nag mails because the project manager thinks you haven't triaged your bugs but your process is different than other teams, or people screaming at you because bugs are not assigned to a specific individual person and are instead on a bug backlog. I'll stop ranting now, but just know that these things can be a reality even in great software companies.

Motley: Enough! Enough already! You are going to make me start pulling my hair out just thinking about it, and I really don't have that much hair to begin with.

I understand the need for milestones. From my perspective of being on an agile team, we keep going as usual, make sure we integrate on a regular basis, be strict about our meaning of "done" for tasks, fold the exit criteria for milestones into our everyday development and guess what? Our team won't struggle through trying to meet exit criteria in the high pressure closing of a milestone. Smooth sailing.

Maven: That's the spirit. Your team is going to rock.

______________________________

Maven's Pointer: Learn the intricate details of the milestones in your company. At Microsoft, practically every team has a "code complete" milestone. Most developers take that milestone for granted. However, the definition of "code complete" is different on every team. Do all features need to be done? Are to-do's allowed in the code? Do you need to run static analysis prior to code complete? Is some measure of API documentation required by the milestone exit? Learn what "code complete" and the other milestones mean on your team and address the exit criteria early.

Maven's Double Pointer Indirection: Avoid cheating on the exit criteria when the end of a milestone draws near and the project manager does not want to change the date. You are only cheating yourself. Do your best to meet the exit criteria and maintain high product quality even in early milestones. Revisit the exit criteria for future milestones if the exit definition is too strict.

Maven's Resources:

None this time

Motley says: "If computers can efficiently multi-task, so can I!"

James Waletzky — Tue, 26 Feb 2008 19:27:00 GMT

Summary

Motley: I ultimately finish my tasks sooner by doing multiple things at once. If Microsoft Windows can multitask, so can I!

Maven: Work on tasks serially, one at a time. Finish one task before moving on to the next. Context switching severely hurts overall efficiency.

______________________________

[Context: Motley and Maven are continuing their discussion Scrum and this time talking about multi-tasking]

Motley: What's the problem with doing multiple things at once? I have no trouble keeping a bunch of stuff in my head at once. I do a little bit of one task, a little bit of another task, a little bit of a third, and so on. I finish the set of tasks sooner this way. Can't you walk and chew gum at the same time?

Maven: Sure, I can do two things at once, as long as one of the things I am doing is habit and does not require thinking. Walking is habit. I can do it without engaging my brain. I may have to engage my brain to figure out where I am going, but once I am pointed and start walking, I can easily do something else at the same time, like read or listen to music. Once I come to an intersection, however, and have to figure out which way to go, now my brain is engaged, and I stop the other thinking activity, such as reading.

Motley: Remember the other week when you were staring at that pretty girl while walking and you ran straight into that pole and bruised your cheek? You're not so good at multitasking are you!

Maven: You said you were not going to bring up that incident again.

Motley: Couldn't resist. You are easy to make fun of. Anyway, Microsoft Windows is efficient at multi-tasking. I can have multiple processes running at once, which turns out to be extremely efficient much of the time.

Maven: It turns out the human brain is not to good at switching thoughts randomly. Here is a quick exercise you can try that proves the point. You need a pen and paper to play along. Got one?

Motley: Why would I want to play whatever game you have in mind? I'd rather do magic and make you disappear! Hehehe. Sometimes I'm pretty funny.

Maven: Ha ha. Wise guy. This is a really quick exercise that proves a valuable point. You made the claim that you are most efficient doing multiple tasks at once. Let's illustrate what happens when you multi-task-

Motley: <whispering> Pssst… Mave. James is listening in again.

Maven: It doesn't matter. Maybe he, and whoever he tells this story to, will play along. Anyway, I am going to give you 10 seconds to write down all the letters from 'A' to 'Z' in order. Ready? Go.

Motley: <writing>

Maven: Stop. How far did you get?

Motley: Easy. I almost finished. I got all the way to 'X'.

Maven: Good stuff. You're a pro.

Motley: What does this prove?

Maven: Nothing yet. Let's do part 2. I am going to give you 10 seconds to write down all the numbers from '1' to '99' in order. Ready? Go.

Motley: <writing>

Maven: Stop. How far did you get?

Motley: Is this supposed to be challenging? I'm sure I got more than the average person. I got 21.

Maven: Nice!

Motley: My patience is wearing thin, Mave. What is this supposed to prove?!?!

Maven: One more. Now I am going to double the time to 20 seconds, and you are going to write all the letters from 'A' to 'Z' and numbers from '1' to '99' in order but alternating between letter and number. For example, the list would start out as 'A1', 'B2', 'C3', etc. Ready? Go.

Motley: <writing>

Maven: Stop. How did you do?

Motley: Pretty good. I got to 'M14'. Pretty impressive, huh?

Maven: But I gave you double the time as last time. Why didn't you get at least to 'U21'? You got to the number '21' previously. Why couldn't you match it?

Motley: You made me do two things at once! My brain has to shift gears every time I go from a letter to a number. Duh!

Maven: Exactly! When you change from one task to another, your brain as to make a similar switch in context. But this time we aren't just talking about letters and numbers but perhaps one complex coding task to another. This is why, regardless whether you use Scrum or some other project management technique, you always want to finish the task you are working on before starting another. Have one primary task, and have another one in reserve in case you get uncontrollably blocked on the first one.

Motley: You know what I can't stand? You. When you're right. Grrrr. I always tell my team members that they should cut off Outlook, Messenger, alerts, stock quote tickers, etc. that provide constant interruptions when they are trying to get in the "zone" to get some real work done. It boils down to the same reason. I must not have had my morning caffeine today. I apologize for that.

Maven: No problem. Computers are good at multitasking within certain constraints, but we're not so hot.

Motley: Actually, computers aren't that great either. If you design an application that uses too many threads and the operating system has to keep switching between them, the context switch is significant overhead and may involve paging memory on and off disk. Same concept. Of course, we can have computers with multiple cores and if we create one thread per core with nothing else going on, then multitasking can be efficient. I guess that is the equivalent of having two brains, though.

Maven: Nice. Great point there Mr. Motley.

Motley: I'm full of good tidbits. Now, if I can only do one thing at a time, I choose getting some real work done over talking to you. Goodbye.

______________________________

Maven's Pointer: Recently we talked about data gathering with Scrum, and analyzing Burndown charts with Cumulative Flow Diagrams (CFD). One characteristic of the chart to pay attention to is a wide yellow section representing in-progress tasks. If the team has too many in-progress tasks, it is likely not being as efficient as it could be. Keep the number of in-progress tasks to a minimum to ensure the team is not multitasking. Each team member should work on one task, and have a back-up should they get blocked. The yellow section on the CFD should be as thin as possible.

Maven's Resources:

Do you have Office Attention Deficit Disorder?, by Tom McGrath, Men's Health, http://men.msn.com/articlemh.aspx?cp-documentid=5513983&page=1

A favorite quote from the article: ""Every e-mail interruption is like a hand grenade being thrown in the middle of your brain," says Dr. Hallowell."

The Autumn of Multitaskers, by Walter Kirn, TheAtlantic.com, http://www.theatlantic.com/doc/200711/multitasking

Motley says: "What does Rugby have to do with software?" (Scrum Part I)

James Waletzky — Tue, 22 Jan 2008 19:03:00 GMT

Summary

Motley: Scrum? Does that mean team members have to carry a ball and tackle each other in the hallway?

Maven: Scrum is an agile project management methodology that follows agile principles. The process is build a product backlog, plan the sprint, execute and meet daily, demo the work, do a retrospective, and repeat.

______________________________

[Context: Motley has been thinking about how to apply agile principles to an overall project schedule]

Motley: We talked about agile development in the past, and now I am trying to figure out how it applies to running a project. We chatted about Test-Driven Development (TDD) as a development practice, but what about overall project scheduling? Are there any agile methods for that?

Maven: Yes. Actually, one of the most popular agile project management methodologies is "Scrum".

Motley: "Scrum?" Isn't that a Rugby term? What the heck does Rugby have to do with software development?

Maven: No padding and lots of people get hurt.

Motley: Ha! Mave actually has a bit of a sense of humor. And I thought the only thing funny about you was your haircut!

Maven: What's wrong with my haircut?!? Never mind. Anyway, Scrum is an agile project management methodology that focuses on the agile principles we talked about previously, namely short iterations, continuous improvement and feedback, embracing change, and collaboration. It is a simple, lightweight process that has many benefits.

Motley: Do team members have to carry around a ball and tackle each other in the hallways.

Maven: It's not mandatory, but if you feel it makes you more productive, go for it! Well, on second thought, don't. Might not be best for team health. I've got lots of experience with Scrum and it is a fantastic way to run many types of projects.

Motley: This agile thing is actually pretty cool and has some benefits. Okay, I'll ask. I am curious how we could apply it here. What is this "Scrum"?

Maven: Scrum is all about running projects in an agile fashion. It's not about doing development. First, let's see how Scrum fits into the agile principles we discussed previously:

Keep it simple: Scrum itself is a very simple, lightweight process that allows us to keep development simple.
Embrace Change: Scrum encourages work in small chunks. We focus for short time periods but in between those periods we can re-prioritize the work we do.
Incrementally iterate: We build an application in small chunks over iterations that last no more than 30 days.
Continuous feedback and improvement: At the end of an iteration of work, we always look back at how we did and figure out what we can do differently next time to improve.
Collaborate: Scrum strongly encourages communication and collaboration among team members. It doesn't work without it.
Eliminate waste: Scrum helps us only do work that adds value to the customer or the team.

Motley: Ok, I remember those principles. You're not giving me much here though. How do I practice Scrum?

Maven: Scrum can be broken down into a few key steps. Before we do that, I need to cover a few basic definitions:

Product Backlog: think of the product backlog as a high level, prioritized list of everything you want to build. These can be user stories as used by Extreme Programming or simply one-liner feature descriptions. The important part is that the work is prioritized. As you pull items off the list to work on, you always work on what adds the most value.
Sprint: A sprint is a short iteration of work that happens over a maximum of 30 days. A sprint has a goal associated with it.
Sprint Backlog: A list of work items for a sprint. A sprint backlog starts with some items from the product backlog and then breaks them down into specific tasks, each with a meaning of "done" associated with it.
Product owner: The person that is responsible for maintaining the product backlog and making decisions about feature priorities. The product owner is usually not an active team member during a sprint.

Motley: You're already getting technical on me. What's with all the new terminology? Why not something simpler like "feature list". Wouldn't that be more in line with agile principles?

Maven: Hmmm… don't know what to say there. I guess the "product" part emphasizes the long-term nature of the list, and the backlog is stuff that we haven't yet gotten to. Makes sense. With "sprint", we are running a marathon (building the product) but doing it in short bursts (iterations) with breaks in between.

Motley: Fine, fine. I'll get used to it. What's the process?

Maven: It's actually quite easy. Here it is:

Build the product backlog
Plan the sprint
Execute and meet daily
Show a demonstration of completed work
Do a retrospective
Have some slack time, and repeat

Motley: That's it? Sounds pretty simple. Obviously I need a bit more detail on those steps.

Maven: Your wish is my command!

Motley: Get me a burger.

Maven: Not every wish is my command! Let's get back to Scrum. I'll give you a quick overview of the steps in the process first, and then in a later conversation we can go into some best practices for each of the steps. Sound okay?

Motley: Sounds better than an enema. Get on with it.

Maven: When you build the product backlog, the team, together with the product owner, determines what features are important to the customer and creates a stank-ranked (prioritized) list of all the features. The most important features are at the top of the list.

Motley: This requires some up-front thinking - isn't that contrary to agile?

Maven: This is planning on a very high level. It's our rough vision for what the user wants as of today. It could change tomorrow. The next step is to plan the sprint. Here we take the top priority items from the product backlog and plan to delivery them in completed state. How many? As many as you think you can build in the current iteration. We then break down each product backlog item into sprint backlog tasks and start executing.

Motley: Cool. Sounds easy. But how do I know what to work on next?

Maven: Each person should be assigned one task during planning so that they know what to work on. After that, as you finish a task, you take another one that is unassigned and is the highest priority. After we have a plan, we then execute and meet daily. We work through the sprint tasks and everyday we estimate how much time is remaining on the task. We are always realistic with ourselves about how long tasks take, and if they take longer than normal, we start cutting tasks that are lowest priority. Also, every day we meet for a status meeting.

Motley: Ok, now you are off your rocker! You want to have a status meeting every day? One status meeting a week is painful enough. I think you have been into the glue again.

Maven: I admit - it sounds crazy. But the meeting is very short, like on the order of 10 minutes for a small team of 5. I can talk about how to keep it short later, if you like. After the sprint is complete, we show a demonstration of completed work. This short meeting allows the team to celebrate what it has done and inform stakeholders of completed work.

Motley: I am assuming the customer, or the voice of the customer like the product owner, is there? They are probably curious to see the work.

Maven: Absolutely! Anyone with a stake in the project, including the customer, should be at the demo. The sprint ends with a retrospective. This is the team's chance to look at what went well (and continue doing it) and determine what we can do differently to improve next time.

Motley: Ah, the continuous improvement piece. Pretty straightforward process. I like it.

Maven: After the current sprint is done, you reprioritize the backlog once again and have a new planning session. Then you do it all over again and deliver yet more value to the customer.

Motley: Well, let me try it with the team and do a two week sprint. Perhaps you and I can have a retrospective in a couple of weeks and you can give us a few more tips.

Maven: Wow - look at that pig flying! You actually want my help?!?

Motley: <silence>

______________________________

Maven's Pointer: As step 6 in the process states, it's important to have at least a couple days of slack time in between sprints. Give the team a chance to take a breather and catch up on some non-sprint activities. This is a good chance to catch up on some technology or tools issues and regroup. You'll find yourself more effective by slowing down. It's called a "sprint" for a reason - you cannot sustain the pace indefinitely.

Maven's Resources:

Agile Project Management with Scrum, by Ken Schwaeber, Microsoft Press, ISBN: 073561993X, March 2004.
Ken Schwaeber's Company: http://www.controlchaos.com/