If you are a regular reader, you will know I have been managing teams using Agile for years. Through much trial and error I have landed on this sprint calendar as the most productive. Please comment if you have a different approach you have found to be the most productive.
T-5 (read tee minus five) Pre-Pull: this is the Monday before you start coding, folks take 15 minutes at the beginning of the day to guess what they will pull off the backlog for this sprint. The goal here is to allow folks supporting the developers to have a head start with creating design assets, writing down feature requirements, coordinating with partner teams, etc. Yeah, some of the items will not make the sprint but it means the devs will have something to start with on the first day of coding. Backlog grooming will happen throughout this week.
T-2 Pre-Check: this is a non-dev review of the prep work for the pre-pull items. The goal here is to make sure folks are on track with the pre-pull items and to provide feedback on any issues found that might impact the sprint. Basically its all about being ready for the devs on Monday.
T1 (read tee one) Sprint Start: the first Monday of the sprint, items are pulled off the backlog by devs based on what they *feel* they can finish this sprint. Devs then immediately sit with their feature crew and map out what they are building and what design assets they need as well as questions answered in the feature wiki. Once they have a good idea what they are going to build they immediately create interface stubs. This is one of the most over looked aspects of agile as it dramatically increases efficiency. Devs check in stubs by end of day Monday.
T2 First Build: first thing Tuesday morning test to kicks off an integrated build of the stubs. Remember this from CS 101, build early and often? From this day on, test will complete an integrated build every day and run test automation. This will flush out interface issues and break the critical path in areas where developers must take dependencies. Now many of you are saying WAIT, developers cannot take a dependency on a current sprint deliverable! Wherever possible this is correct, but in the real-world often this is simply not possible. So have devs create stubs and build early. Not only will this drive code alignment it will force the dev to actually think through the whole system early in the cycle which will eliminate the surprise, “I just did not realize how big and complex it was”, escalation from the dev on day 5 of the sprint.
T2-T5 Just Keep Coding: these are the big productivity days so all hands on deck supporting dev delivering as much code as possible. Note, in parallel with this first week of coding, test is verifying the final build from last sprint. Bugs from that verification may disrupt this sprint if they are determined to be higher priority that items pulled for this sprint. OK, more folks saying WAIT, you cannot change the scope of the pull for the sprint, any new bugs have to wait until the next sprint. Again, sure, wherever possible this is true but in my experience you will find bugs that have to be fixed or you cannot ship at the end of this sprint and if shipping is important this sprint then you better flex the *rules* a little.
T6 First Test Drop: since on T5, test completed verification of last sprint’s build, it is time to get them focused on testing this sprint. I know, I know, lots of companies only have devs and there are no dedicated testers. Sure but in a given sprint code must be tested, now is the time, if not things will never converge. Whoever is responsible for testing this sprint better get on it T6 or this sprint will NEVER ship. Devs HATE this day. They bitch to high hell about how they are not ready and they will deliver a testable build on Tuesday or Wednesday. Here is what I say about that, HAH, yeah right. If Dev does not deliver a testable build on T6 you will not ship.
T6-8 Feature Completion: starting week two of the sprint, devs should not be checking in any big new features. The first 3 days of week two they should be flushing out and completing features they checked in at the end of week one. This stage is when things converge.
T8 Code Complete: at the end of day eight devs have to have all of their features complete.
T9-10 Bug Fixing: on the last two days of the sprint devs should only be fixing bugs. If they do not have bugs to fix then they should be working on private builds of features they expect to work on NEXT sprint. In practice this NEVER happens. Devs will be fixing bugs and fixing bugs and fixing bugs these last two days.
T10: Demo Day: coolest day of the sprint, demo day. End of the last day, bring in beers and snacks and let everyone show off they work they have completed. This is critical to the agile process. Having a demo day creates accountability and will keep devs from simply coding right up to the last day of the sprint and delivering something that is not shippable. It is also amazing to see all of the progress a team can make in such a short period of time. Right after demo day lock the tree and send everyone home.
T+1-5 (read tee plus one) Build Verification: Monday morning after the sprint, test forks the repository and unlocks the main trunk. Test then produces a production build of the last sprint and starts verification. While I leave up to 5 days for verification, if you use flighting you will not use all 5 on verification before you drop to production or call the sprint as not shippable. I usually see the team make that call on Wednesday. After that, they continue to test the drop through the end of the week logging bugs.
When you string together a bunch of these sprints it looks like this as the first week of dev overlaps with verification of the last sprint and the last week of dev overlaps with the sprint preparation activities for the next sprint.
I have been using this schedule for years and it really works. Once the team settles into this cadence they will really crank.
The Tao of Todd 