Significance of Time Boxing

Everything in Scrum is time boxed - assuming you go by the book of course. Did you ever stop to wonder why?  The Sprint planning meeting is time boxed to two 4 hours sessions (One to define what you’re doing, the other to define how you’re going to do it). The Sprint itself is time boxed to 30 days or less depending on how you’re structuring things. The Sprint review meeting is time boxed to 4 hours as is the Retrospective. So what’s this time boxing about anyways?

Fundamentally, it’s designed to establish a sense of urgency and to coerce the team to focus there efforts on getting something done. This is based on one of the Agile Manifesto that suggests the best way to show progress is to produce demonstrable working product, not documentation - Wow, what a concept! That’s not to say you don’t need documentation. In many cases this is required for ISO, FDA and other standards, but documentation is just one of the artifacts that needs to get produced during the course of the sprint – it’s not the bee-all and end-all.

Traditionally developers left to their own devices, do things the waterfall way – this has been in-grained over years and years of training them to do  it this way. So emphasis on precision, accuracy and detail were the order of the day. This led more often than not into analysis paralysis, and large amounts of extra effort into designing for goliath when you’re only intending to ship david. Through waterfall, you were only given one shot to get it rights so we forced product managers to think of ABSOLUTELY everything. And of course developers therefore had to design for ABSOLUTELY everything.

The theme behind time boxing is the concept behind Just in Time manufacturing and emergent thinking and dare I say this “Good Enough”!. You plan and design for what is most important at that time. Nothing more, nothing less. And the architecture and product grows, emerges, and is refactored to deal with new requirements as they pop to the top.

This is not an impossible feat, it’s been done many times over and over. If I told you that we built our software and tracked our own software development using our own product since the 3rd week in development would you believe me? This is absolutely fact. There was no such thing as loosing data for us. Rather the schema and the data and the architecture grew as the requirements grew. And everything emerged systematically as the scope increased over time This is pretty much unheard of in our industry. And until such time as your Product Owner says it’s good enough, you continue to expect change and evolve the product over time.

This is a huge change in mindset and it takes hard work and good engineering practices to do it this way. So for example if you don’t have an automated test harness, and you don’t have significant unit test coverage (we have 100% unit test coverage), you’re not going to be able to work this way.

While on my Scrum training with Ken Schwaber (highly recommended by the way) one of the team members at my table asked how we managed to keep our developers productive when there’s so much testing that takes place prior to the end of each sprint. Well believe it or not, there’s lots and lots of stuff that developers have to work on besides getting to code complete (what this means is subject for another blog) and throwing it over the fence to QA to test. To name just a few of these tasks, automated test scripts, integration test scripts, design docs, coding standards, unit tests, integration test scripts, production deployment scripts, performance monitoring scripts. To build sound well engineered products there’s no shortage of work to get done.

Although I am not that hung up on the length of some of these meetings (in particular the Sprint Planning meetings, especially if it’s your first sprint planning meeting and the first time this team is working together) I still think that they represent good guidelines and should be adhered to if at all possible.

If during the time boxed sprint planning meeting, you’re not able to complete the task breakdown, don’t sweats. Let the tasks emerge overtime. During the Sprint as things evolve and knowledge is gained, new tasks can be added by the team to the backlog. People, especially engineers are intelligent human beings and left to self manage especially in a team setting will figure it out believe it or not! So don’t be scared to dive in and get your feet wet even when you don’t know the full picture. Use the time boxes to get you going. Just make sure you don’t leave the engineering practices behind. 

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com

 

Comments

[Erin Quick-Laughlin]

Great post Jack - what test harness collection are you currently using? For our next product, we're looking at a combination of CruiseControl.NET based on this article: http://www.developer.com/net/net/article.php/3557396 . It seems like a pretty good place to start, given our framework. We just need good JavaScript unit testing as well, perhaps JSUnit? What's your experience in setting up a good testing harness for RIAs?

--
Erin Quick-Laughlin
Principal, Project Manager, RIA-SOA Architect
Nth Penguin, LLC
http://www.nthpenguin.com
Inquire: 1-920-574-2218
--
President of Midwest Agile
http://www.midwestagile.com
--
LinkedIn Profile: http://www.linkedin.com/in/erinql

[Jack Milunsky]

Hi Erin,

Thanks for the comments. We are a Rails shop so we use RSpec and Cucumber. We test 100% of our model code which is 99% of the logic. And a bit of our Model code. Views we haven't done much with though - I have to admit.

Jack

[pariul zilei]

Interesting info, do you know where I can find similar information? I’ve been trying to find out a little more about this kind of stuff, thanks for sharing it.

[Jack Milunsky]

You can try Mike Cohn's site - he may have some more info on this topic. I am not sure off hand without doing a lot of digging where to find this sort of info. Feel free to ask me any questions.

Jack

[smithkline]

If during the time boxed sprint planning meeting, you’re not able to complete the task breakdown, don’t sweats. Let the tasks emerge overtime. During the Sprint as things evolve and have the gains. Use the time boxes to get you going. Just make sure you don’t leave the engineering practices behind. i like to
watch pacquiao vs mosley, it is really a tough competition.