OpenCraft's sprints are jam-packed with client tasks, forum discussions, mentoring, context switching, planning for next sprint, epic project budgets, firefighting, discoveries, more context switching.. in short, there is a lot of work to do, and only one sprint to do it in. So how do we do it all, and not go crazy?
The short answer is, we all go crazy some of the time :) But the goal is to find your own balance, with sustainable work practices that improve your productivity and lower your stress.
On this page, we'll share some tips and strategies for time management.
Take real breaks
Really. Sometimes the best way to manage your time, especially when everything feels overwhelming, is to walk away from your desk for a while -- mentally, as well as physically.
If you're having trouble working through a sticky problem, or finding it difficult to focus, or getting stuck down in the weeds of a ballpark estimate instead of staying up at the high level, that's a good time to take a break. Do something that really does take your mind away from the pressing issue: take a walk, listen to a podcast, read something unrelated, have a cup of tea, pet your cat, talk to a friend.
As with everything, the more breaks you take, the better you'll get at taking them, and at achieving the mental block release that they provide.
Assess your sprint
Every couple of days at least, it's a good idea to take stock of how your sprint is going. We suggest you print out a copy of Are you feeling productive? and keep it near your desk, as a reminder.
- Are you feeling unproductive?
- Are you running behind at all?
- Is this task taking longer than you estimated?
- Is this task more complex than it sounded?
- Are you doing more than the task requires?
If the answer to one or more of these questions is "yes", then it's time to do something about it.
- Who are the two people you should tell?
Some suggestions are:
- Task reviewer
- Epic owner/reviewer
- Sprint firefighter
- Upstream specialist
- Can you split added scope into another task?
If yes, propose the split to:
- Task reviewer
- Epic owner/reviewer
- Can someone pick up any of your other tasks? To find out, ask:
- Sprint firefighter
- On Mattermost
- During the mid-sprint meeting.
Plan your sprint
If you're consistently having difficulty finding time to complete tasks, or are always working in the evenings or on weekends when you don't want to be, then you might need to work on your sprint planning.
Take care to note the timezone and schedule of your reviewer, so you can limit round-trip time for replies. Be sure to discuss when you'll have the work ready for review, especially if your reviewer will be away for part of the sprint.
One approach is to map out the days in your sprint, and as you assign yourself to tasks and reviews in the upcoming sprint, block out the day(s) each task will cover. To limit context switching, try not to have more than 2-3 different tasks in a day, especially at the beginning of the sprint.
You may find another approach works better for you, but the important thing is to have a strategy, and tune it to ensure that it helps your sprint and stress levels.
Improve task estimates
If you're using the Sprint planning report to avoid overcommitting, but you find that you're consistently logging more hours than you initially estimated, then you might need to work on improving your task estimates.
One of the common traps when taking on a task is to "estimate" it by looking at the hours you have remaining on the Sprint planning report, and using that to determine how much time the task will take. This consistently skews estimates into being too small, so don't do it! Please evaluate each task independently, based on time required to achieve its acceptance criteria, not how much time you have left to do it.
If the scope of your tasks grows beyond what you expected the task to be, then it's best practice to split this extra work into another task. Splitting tasks isn't just about semantics, this is part of how we keep our client commitments within bounds and on time.
Use JIRA to list your tasks which had more hours logged than originally estimated, and at the end of each sprint, spend some time assessing them to see if you could have done anything differently. Ask your reviewer or the epic owner if they have any ideas too.
"Spillovers" are tasks which didn't reach a Done or External Review/Blocker before the end of the sprint. There's several reasons why this might happen, and everyone on the team will have spillovers from time to time. But the goal is always to reduce and eliminate spillovers, and have clean sprints.
Why are clean sprints so important?
At OpenCraft, we deliver what and when we promise. All our projects and tasks are planned based on expectations of work being completed in a certain timeframe. Not just our clients, but also our internal sprint managers, sustainability planners, and epic owners and reviewers need to know that we can complete our commitments on time.
That's why, at the end of each sprint, we spend time going through the list of tasks that weren't completed during the sprint, and asking ourselves, "What could we have done differently to prevent this task from spilling over?" The use of the word "we" is intentional here, because a sprint is a team effort, and so spillover is not a single individual's failing. Task reviewers, mentors, and sprint firefighters all have time set aside to help complete tasks, and it's ok to lean on them and ask for help.
This is also why we have a minimum spillover allowance for newcomers, because we need everyone to take spillover seriously, and to know that everyone can improve.
How to address spillovers?
Here are some of the ways to reduce and eliminate spillovers.
- Track your own spillovers and reasons.
This makes it possible to identify the most common reasons for spillover, and to figure out what you need to work on.
- Improve your task estimates.
If you're consistently logging time over your tasks' Initial Estimate, then this makes the Sprint planning report a much less useful tool. See Improve task estimates for ideas and tips.
- Take on tasks which are related to reduce context switching.
If there are several related tasks in the upcoming sprint, try to take on as many as possible to reduce context switching and setup time. If someone has already taken one or more of these tasks, then feel free to discuss and swap assignees around. It's always ok to ask.
- Ask for advice.
If you're not sure what you could have done differently to avoid spillover on a task, ask your reviewer for recommendations, both early in the sprint and when spillover is apparent. We should also always pay attention during the sprint review meetings for ideas from other people, so you can avoid the same mistakes.
- Avoid scope creep.
This is easier than it sounds, because often, the scope creep comes from us being good engineers, trying to do more than the task requires. Sometimes scope creep comes from consultation with the client, but it's still ok to manage expectations and negotiate these additions if they come up. When you assess your sprint, watch out for opportunities to split follow-up work into a new task, to be completed next sprint, and ensure that these tasks are communicated to the epic owner and/or client.
- Limit review cycles.
Discuss the task with your reviewer early in the sprint if there's any ambiguity about the acceptance criteria. Plan your sprint to accommodate timezone disparities or any planned time off.
- Use timeboxes to get started on tasks that you don't have time to complete.
Ideally, a task would be split in two so that something is completed during the sprint, e.g. if a task can be split into a small timeboxed discovery or prototype task, and an implementation task. This must be done before the start of the sprint and in consultation with the epic owner, but it's a good way to maintain momentum on a project.