An Agile Dilemma - How to start the Sprint

July 18th 2011

Imagine it's the first day of your 2-week sprint (iteration, etc.), and you're eager to get started. Your burndown (or task list, etc.) has just 4 tasks:

Task Estimate
1. Implement "Order Status" screen. 35 hours
2. Print username in system logs. 2 hours
3. Investigate clustering in Tomcat. 15 hours
4. Upgrade to newest version of GWT. 20 hours

The question is, then, how do you get started? What do you do on that first day? You've committed to completing all the tasks, so does it matter? Of course it does.

Two simple approaches are...

1. Start with the tasks that are most fun. "Investigating clustering" sounds interesting, so start with that! This makes for a more enjoyable least for the first few days.

2. Knock off the low hanging fruit first, and get some quick gratification at the beginning of the Sprint. Just like some financial gurus say to pay off your lowest debts first, it's nice to build some confidence before you get to the tough stuff.

Honestly, I find it really tough not to use these strategies - I just naturally want to do the fun tasks or quick-wins first...but having lived through more than a few failed sprints, I've quickly learned better.

First, there are some tasks which other developers are depending on me for (e.g. "Upgrading GWT"), and so if I wait till the last few days to do this, I effectively hose my colleagues. Second, there are times when I don't finish all of my tasks (gasp!) - maybe I had to call in sick one day, or requirements shifted, etc. If I do the most fun tasks first, I may have left some high value tasks hanging.

So here are some more disciplined approaches:

3. Start with the task that has the most dependencies on it (either within my own task list or for other developers). This approach is the best for keeping you in the good graces of your team.

4. Find out from the business owners which tasks are the highest value and work from high value to low - that way if something doesn't get done, it will be less of a big deal. For example, the "Order Status" screen might be crucial to the business, but "Upgrading to GWT" is not as big a priority.

5. Dig into the task that is the most complex first, so you can identify and mitigate the biggest risks right away, and you'll have more time to address them during the sprint than if you waited to the end.

Now each of the last three approaches (which can be blended, of course), are significantly more disciplined than the first two, but there's still a problem...

Most developers (me included) typically like to work sequentially - complete a task, move on to the next one. I find this more gratifying (and less stressful), but not very effective. It's very possible that lingering within each of my tasks is some big gotcha, that needs time (i.e. calendar time, not hours of work) to be dealt with. For example, maybe there's some question about the "Order Status" screen that needs to be posed to a business owner, and that business owner is booked solid till Thursday. Or maybe investigating clustering requires the assistance of a sys admin, and he needs a week lead time. If I don't identify these dependencies early, I could easily put myself in a position where I can't complete my tasks.

Given this, I've found the most effective approach to starting the sprint is this...

6. On the first 2 days, take a spike through each of my tasks (similar to the XP concept), understand better the requirements, and pick out the tricky pieces that might require input from others. This may require writing some code, but not much. Once I have a good handle, at a conceptual level, of what each task entails, then I can use some blend of strategies 3, 4, and 5.

The biggest drawback to this approach is that on those first two days, I find myself barely burning any work down - because most of what I'm doing is asking questions and planning. After everything is in order though, I typically can roll smoothly through my work.

Anyway, what are your thoughts? How do you start your sprint?

I'm an "old" programmer who has been blogging for almost 20 years now. In 2017, I started Highline Solutions, a consulting company that helps with software architecture and full-stack development. I have two degrees from Carnegie Mellon University, one practical (Information and Decision Systems) and one not so much (Philosophy - thesis here). Pittsburgh, PA is my home where I live with my wife and 3 energetic boys.
I recently released a web app called TechRez, a "better resume for tech". The idea is that instead of sending out the same-old static PDF resume that's jam packed with buzz words and spans multiple pages, you can create a TechRez, which is modern, visual, and interactive. Try it out for free!
Got a Comment?
Comments (7)
July 18, 2011
I would start by getting the job done rather than wanking over badly defined productivyt "science".
July 18, 2011
In general, I think it does not matter how you go about running your sprint as long as it all gets done. But some tasks that require input from others cannot be compressed on the calendar. I would think you need to identify and start those tasks first.
July 18, 2011
@JayCee - definitely a fair point. There are definitely places where it's better to just start doing rather than think about doing. However, I gotta stick by my post (which in no way do I claim is science, btw!) - I've seen a ton of developers (me included) just dig right in to their tasks with no rhyme or reason...and then get burned with 2 days left in the sprint because the business owner is booked and they can't get feedback on their tasks...or they didn't realize that to upgrade some library requires someone else to refactor their code and they weren't given enough lead time.

@MaintenanceMan - thanks. Yup, totally agree...and when each task requires input from someone, I've found it important to front load and get that input all at the start of the sprint if I can.

July 18, 2011
How about breaking your tasks down in smaller pieces of let's say 4 hours max?
July 18, 2011
I'd break the 'Implement "Order Status" screen.' and 'Upgrade GWT' tasks down into subtasks first. That'd should have been part of the discovery stage, prior to starting the sprint.

As JayCee said, leave the burndown obsession to management and work out what you need to do, then start doing it.
Dan the Man
July 19, 2011
Hmmmmm.....First...I would start by pointing out that the "tasks" are really more like poorly written Story's. I would have expected statements such as these to be what I walked into the sprint planning meeting with....not starting out on my first day of a two-week sprint...Second...As far as which stuff to work on's a balance between priority that has been set by the business stakeholder and dependency with other efforts going on in the sprint. Again...all of this is defined back in the sprint planning meeting...Third...If "architecting" a solution is left for each developer to do during each Sprint, there won't be much in the way of consistency in the finished product. Again...epic failure during the sprint planning meeting! Hello...wake up Mr. ScrumMaster! He/She should have called bullshit before you even got started!
July 19, 2011
Thanks for the comments.

I think maybe some bad fabrication of example "tasks" is obscuring the general point....

...basically, on your burndown you have a handful of tasks (call them "A", "B", "C", etc.). Some of these tasks are "fun", some have dependencies, some are risky, some are complicated, etc. Now, you can just pick tasks off randomly and work on them sequentially, but it's very possible that when you get to task "E" with 2 days left in the sprint, you may not have identified some hidden "gotcha", and you don't have enough calendar time to resolve before the end of the sprint. Not everything is caught in the sprint planning meeting, because this isn't waterfall, and not everything is worked out ahead of time.

I appreciate the points though - and perhaps part of the answer is better planning on both the parts of the manager and developers.