An overview of my planning and productivity system in 2021

Google Calendar, Microsoft OneNote, Trello and Todoist

A couple of years ago, I wrote a post called An overview of my planning and productivity system in 2019. I was discussing it with a couple of people last week and thought it was probably about time that I updated it to reflect how things have evolved during that time.

During the last few years, my basic tools have not changed. As I said in my last post, for a long time I tried to limit myself to using only one task management application. I would periodically switch between Trello and something else (Outlook tasks, Wunderlist, Todoist). Eventually, I realised that I could use different tools for different jobs. For me, a good organisation system should enable you to do the following, and this is what I use:

Continue reading An overview of my planning and productivity system in 2021

Tracking my food in Trello

There is a business analyst saying that “If you don’t measure it, you can’t control it”.

With it looking ever more likely that the UK would soon lock down, on Sunday afternoon, I removed all the food from my cupboards, my fridge and freezer and have recorded it in Trello.

Continue reading Tracking my food in Trello

The importance of small user stories

Battleship beneath a grey cloudy sky
“Grey and black boat under grey clouds” by Will Esayenko on Unsplash

I’ve been thinking a lot recently about the size of user stories in agile projects. The idea that I’ve been reflecting on is what if teams only worked with small, similarly-sized pieces of work, rather than exponentially larger blocks of work?

In theory, small user stories should be more predictable, should include less risk, less uncertainty and less complexity. They should, therefore, take less time to complete than larger user stories… you would think! Or as Mike Cohn put it in Agile Estimating and Planning (Prentice Hall, 2006), “small stories keep work flowing”.

Continue reading The importance of small user stories

Sprint planning in Scrum

At our last retrospective, the Vision Tasks team decided to restructure our sprint timetable. With our two-week sprints running from Monday to Friday, it felt disjointed holding the end of sprint review and retrospective on the Monday morning of the new sprint; sprint planning was then squeezed into a one-hour slot on Monday afternoon.

With the new timetable, the sprint review and retrospective are now held on the afternoon of the last Friday of sprint. This should help us round off the sprint nicely without the hiatus of a weekend. But it also frees up the whole day on the first Monday of sprint for planning, which is what I want to explore in this post.

Planning in two acts

During sprint planning the team is asked to answer two questions:

  • What can be delivered during this sprint?
  • How will this work be achieved?

These don’t need to be separate meetings but what is important is that both questions be answered: what then how.

In my experience, new teams often only answer the ‘what?’ They drag enough stories onto the sprint backlog to match their velocity then kick-off the sprint with no real sense if what they have committed to is achievable or not.

The ‘how?’ part takes all the Scrum values to work at and perfect: commitment, courage, focus, openness, and respect.


There are three things required going in to a sprint planning meeting

  1. a refined, prioritised backlog.
  2. an understanding of the team’s velocity, that is how many story points a team can complete in a sprint.
  3. an understanding of the team’s capacity for the next sprint, in hours.


When working out the team’s capacity for development work, each team member should take the total number of hours for the sprint (number of days × hours worked, e.g. 10 × 7 hours) minus any time spent in meetings (daily scrum, backlog refinement, sprint review, sprint retrospective and planning).

Then deduct an hour or two of ‘slack’ for each day to account for dealing with email, distractions, requests from other teams, etc.


The Scrum Guide sets aside a maximum of eight hours for a one-month sprint with a recommendation that shorter sprints are proportionally shorter. So, around four hours for a two-week sprint.

Part 1: What can be delivered during this sprint?

During the first part of the meeting, the product owner presents to the team the next-highest priority items on the backlog. Using the team’s velocity as a guide, the team estimates how much work they think they can deliver during the next sprint.

It can be helpful to keep an eye on the team’s definition of ready to determine whether stories are ready to be pulled onto a sprint, and the definition of done to be clear about what will need to be done to deliver it.

If any new information or insights have come to light, this is the last opportunity before the sprint starts to re-estimate any stories.

Part 2: How will this work be achieved?

Where I have found many teams go awry is that they have misunderstood the Agile Manifesto’s statement about “responding to change over following a plan” to mean “don’t have a plan”. It surprises them to learn that actually more planning is asked of them.

User stories, remember, are not requirements. While they represent user requirements they don’t document them. They are reminders to have conversations to figure out what needs to be done and how to do it. That conversation starts in backlog refinement and gets continued in this phase of sprint planning.

“To acquire confidence in what it can get done, many development teams break down each [user story] into a set of tasks […] The development team then provides an estimate (typically in hours) of the effort required to complete each task. Breaking product backlog items into tasks is a form of design and just-in-time planning for how to get the features done.”

— Essential Scrum by Kenneth S Rubin (Addison Wesley, 2013)

It’s up to the team how they do this but each story should be examined one by one, tasked-out and estimated in ideal hours. You may wish to break the team up to focus on particular areas of speciality, or you may wish for the whole team to discuss everything.

There are many benefits to this approach.

First is the wisdom of crowds. Because everybody is invited to contribute their experience and insights into every story, each story benefits from the input of the whole team about how that feature will be built, tested and delivered.

Newer team members get exposure to parts of the application they may not have encountered yet and can ask questions for clarity.

In thinking each story through at a deeper, more practical level, it can reveal things that had not yet been considered. There might be a realisation about the order certain stories need to be worked on. Anything useful that comes from these discussions should be recorded on the card so they are not forgotten.

Because every team member has helped think through every story, if someone unexpectedly goes off sick, other team members can step in to take up the slack more easily.

It is also easier to manage team capacity at this point than during the sprint. Once stories have been tasked-out and estimated in ideal hours the team can figure out who would be best suited for each task. The duration of those tasks then gets deducted from the team members’ capacity totals until there is assurance that everyone on the team has enough work to do during the sprint.

If there is clear shortfall or over-commitment, then the sprint backlog can be adjusted as appropriate: push items back onto the backlog or pull over more, break them down and estimate them.

At the end of this phase of the whole team should be clear about what the sprint goals are and how they will be realised.


The final ceremony during the sprint planning meeting is for the team to vote on how confident it is that it will deliver its commitment. This can be done using Planning Poker™ cards or simple finger-voting, showing one, two, three, four or five fingers depending on one’s level of confidence.

If the team are confident they can deliver everything the sprint begins. If not, they can explore why and make adjustments as appropriate.

Things will change, the team will discover things they hadn’t considered or couldn’t see at the time. Some tasks will be harder than they expected. Others will be simpler. But by taking the time to work together to plan as far as they can see, they set themselves up well for success.

Originally published on the Vision internal blog.

Meet our sprint planning document

Sprint planning document for sprint 62 Elmo, where it usually sits, in plain view on my desk

Let’s say you have a team of eleven knowledge workers, who have a wide portfolio of responsibilities, and you need to get a bunch of tasks done, across multiple projects, within a two-week window. How would you keep focus on everything that needs to be done?

Here’s one of the tools we’ve developed to help us do it: we call the sprint planning document.

Continue reading Meet our sprint planning document