In Retrospect: About the Sprint Planning - Init

<body> <h1>In Retrospect: About the Sprint Planning</h1> <p>This is the second of <a href="http://www.dennisdoomen.net/search/label/InRetrospect">several post</a>s in which I’d like to share some of the things we learned throughout more than 14 sprints of Agile development using Scrum. Some of them might appear as open doors, but I wish I knew or thought about those before I started that project. Just by looking back at the mistakes a team of 10 made in a period of 12 months, they apparently aren’t that obvious. So after having discussed <a href="http://www.dennisdoomen.net/2011/09/in-retrospect-about-requirements.html">requirements management</a>, let’s talk about the sprint planning. <p><a href="http://lh6.ggpht.com/-FgxkybGmYRw/TpUxnVwL0cI/AAAAAAAAIjs/Ty6IPI5ZOSQ/s1600-h/clip_image001%25255B5%25255D.jpg"><img style="display: block; float: none; margin-left: auto; margin-right: auto" title="clip_image001" alt="clip_image001" src="http://lh6.ggpht.com/-tpf1TjoHzqM/TpUxn-EpH_I/AAAAAAAAIj0/6zII8FLv2A0/clip_image001_thumb%25255B2%25255D.jpg?imgmax=800" width="400" height="300"></a> <p><b>Don’t ignore holidays and days off throughout a sprint</b> <p>When calculating the velocity for a sprint, it’s quite common to determine the number of working days and multiply these with the estimated focus factor for that sprint. So if somebody’s holiday ends somewhere throughout the sprint, it seems you’ve everything covered. But don’t forget that people need time to get up to speed on what’s going on in that sprint. Many aspects are not written down, especially doing sprint planning meetings. Somebody else has to spend time to update that person. So either remove an extra day from the available working days or adjust the focus factor. <p><b>Account for the (structured) absence of senior team members</b> <p>This one is really about two scenarios. First off, any software development book will tell you that part-time team members will be less productive than equally experienced full-time team members. The fact that somebody is always out of the office on Tuesday requires him or her some time to get up to date on Wednesday. He may even have been working on something on Monday and didn’t find the time to transfer the task to somebody else. That on itself may cause some slight delay, especially if somebody else depends on it. <p>The other scenario happens when the most senior developers are out of the office for a few days. Normally, those developers will be the ones most capable of catching subtle but important design violations or critical bugs during peer reviews. However, when they’re not in, somebody else will take over the review tasks (hence: peer reviews), and they might not detect these subtle problems. If it’s a bug and you’re lucky, chances are that the skilled tester in your team might find it. But design issues (a.k.a. technical debt) may not become a problem until later in the sprint. Worse, it may even appear that the focus factor was higher than usual. But the fact of the matter is that those decisions will haunt you later on in the project. Deal with that by either reserving some time for ad-hoc reviewing or refactoring. <p><b>Have shorter planning earlier at the day</b> <p>Every sprint planning meeting we had to plan after lunch somehow was a lesser success than the ones before lunch. Obviously, the lunch itself is a primary reason for that. But most people in my office start early, so by the time lunch has finished, they’ve been working for 4-5 hours already. By then, don’t expect them to be focused for another 2-3 hour. <p><b>Everyone is responsible for keeping it short</b> <p>Yes, it’s the Scrum Master who should help the team to focus the sprint planning meeting on its purpose. But that doesn’t relieve anyone from keeping the meeting short. Don’t start a lengthy discussion on how to functionally solve a problem if that’s not absolutely necessary. If the product owner hasn’t done his homework properly, force him to move that story to the next sprint. Also beware for technical peop </body>