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.
How to do estimates includes a list of common items that require logging time. With each task estimate, there are the set factors which are known in advance and unlikely to change and there are the risk factors which are unknown.
Improve task estimates, a checklist
Use the point estimation tables at Task workflows to get fast ballpark numbers for most tickets.
Use this checklist
- when you have exceeded the estimate on a ticket, or,
- when you are chronically underestimating for a particular client or project.
How to use this checklist
- Go down the known column. Enter the time you expect to spend on each item.
Sum that column. This is your ticket estimate. If it is:
- beyond the client budget, go to the client or to the epic owner and say so. Propose a simpler alternative if one exists. Remember: this is the actual time you expect to spend, so if you hide it, you are preventing yourself from being paid a fair wage for your labor.
- beyond the amount of time left in your sprint, timebox it or split it into smaller tasks. Discuss with the client if deadlines will be impacted.
Go down the risk column. Enter the extra time you will spend fixing things. The risk column is the upper bound of how badly a task can go wrong.
- Sum that column. Divide by the known column, for example: 42 hours risk / 6 hours known = risk factor of 7.
Brainstorm strategies for coping with risk before you start work.
- Some work can be billed internally, like Ocim breaking.
- Plan a rollback so that you don't leave the client in worse shape if you need to back out.
- Politely schedule new work in new tickets. Don't permit scope creep.
- Start risky work when you feel fresh. Not on Friday nights.
- Get the client involved early. "We promised X but X also needs Y. Y takes ___ hours to build that we didn't estimate. Do you want Z instead?"
No matter how tight a client's budget is, they will appreciate a discussion of risk. This honesty builds trust. The opposite: hiding the risk and hoping for the best, will destroy trust when budgets and deadlines are exceeded.
Tip: As you go through the checklist, visually picture yourself doing each task.
|Task and Considerations||Known||Risk|
|Setup and onboarding
* A working devstack?
* Read the code?
* Read the existing JIRA comments or other docs?
* All the permissions you need?
* Risk factor: What will you do if your devstack won't provision?
* New code for new features?
* Refactor existing code?
* Find and delete old code?
* Writing tests: take your first estimate and double it :)
* Risk factor: What will you do about unexpected code complexity?
|Coordinating with the client
* Minutes per email?
* Number of emails?
* Risk factor: What do you do about long discussions of unclear requirements?
* Risk factor: What do you do if the client wants a video call?
* Go through the full checklist?
* Provision an appserver
* Risk factor: What will you do if Ocim is not working?
* Code comments?
* Ticket comments?
* Extending READMEs?
|Creating the pull request and sandbox
* Good testing instructions?
* Risk factor: What will you do if the CI is broken?
* Reviewer onboarding?
* Time for manual testing?
* Time for reviewer to read code?
* Risk factor: What can you do if the reviewer asks for significant changes?
|Addressing feedback from the code review
* Update testing instructions?
* Provision new appserver?
* Write comments on ticket?
* Run or update deployment playbooks?
* Risk factor: What do you do if the deployment fails:
* related to your change?
* unrelated to your change?
* How many review cycles?
* Over how many sprints?
* How many hours per each?
* Risk factor: What will you do if upstream requests a different approach?
* Emails, Mattermost, sprint grooming
"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.