Optimizing the number of ideal days in a sprint

Question

Our sprints follow the pattern of a planning game based on a prototype, followed by actual application development with unit test, followed again by integration test and more complete unit tests to try and achieve code coverage goals.

In planning two/three week sprints we often find that after allowing for tasks such as developing prototypes, retrospectives, planning games, and deployment and test support tasks we are only left with less than 50% of the days developing the actual user story functionality - this is in planning, before we even get to the unexpected distractions that can occur in reality. Is this typical, or is there a good benchmark for number of ideal days to aim for? Would we be better to focus on optimizing time spent coding, or simply allow for this velocity in planning.

Answer 1

As a general statement, you should plan based on demonstrated velocity. That doesn't mean you can't try to improve your velocity over time, but this is usually not an overnight change and in my years of experience I have learned that not listening to your demonstrated velocity will get you burned every time.

Moving on to the details, I can tell you that having only 50% of your time going to final code development is perfectly normal. You can look at each other item individually, but unit tests, deployment, and prototypes are inextricable from the rest of development. That said, you could look at ways that people get more value out of those tasks. Test-driven development, for example, integrates the creation of tests with actual coded more completely and it might mean that the act of writing tests gets more code done. Similarly, practices like rapid prototyping which prototype at a higher conceptual level might reduce duplicate work if your developers are coding very hands-on to true-to-life prototypes and then re-coding the final product.

So the short answer is that you aren't in a bad place, but it sounds like there's some frustration and practices that integrate those other parts of development better can give the feeling that you're making constant progress. I'd be surprised if you ever spend more than 55 - 60% of your time writing final code though, so realize that the tangible gains in those practices are small.