You can also listen to this article on Spotify above or on YouTube.
Do you ever find yourself struggling away at something - perfecting it - only to wish you’d spent less time on it afterwards?
Some tasks are like that. They can be done in a day or they can take all week - it just depends how much of a perfectionist you are.
Luckily, building software is the epitome of this type of problem. There is always space for more complexity!
That’s why developers had to come up with ways to make sure outcomes aligned with resources. Or, in other words, how to manage the scope of your tasks or projects to align with the time you can realistically spend on them.
This is timeboxing.
It’s something that’s much easier to adhere to when you use Xembly, so we thought we’d do a deep dive for you and hopefully reveal some specialist insights. We’ll cover:
- What is timeboxing? Agile prioritization through constraints
- The 3 key factors to execute timeboxing well
- Types of timeboxing prioritization variations to try
- The Moscow Rules approach to timebox prioritization
- How can I use timeboxing in my daily non-technical work?
What is timeboxing? Agile prioritization through constraints
Timeboxing is a project management technique where you determine how much time will be spent on a task or project, then you only do the work you can do within that time frame.
This approach maximizes time to value and ensures successful delivery of working software. It means that you need to prioritize tightly the work you choose to do and the features you wish to include. This approach is used within agile project management systems and structures.
How does timeboxing fit into agile?
The philosophy of agile development or agile project management is really rooted in the idea that you don't know what works until it is in the market. Therefore, you need the customer to use your product in order to know how to improve your product, what you have built, what you shouldn't build, what you should get rid of. This agile philosophy means that you need to ship software quickly and early in order to iterate on feedback. Iterating on customer feedback allows you to improve without significant wasted resources.
In a normal agile approach, you might determine what constitutes a minimum viable product (MVP). This is the slimmest version of your product where the core value is still generated for the end user. Once you have delivered the MVP, you can see how that product is used or perceived by the end user and determine your next steps from there.
The alternative to agile is called the waterfall approach. In the waterfall method, you plan everything at the beginning, build it all, and ship a completed piece of software. However, if your assumptions about the customer and the market were wrong, you have wasted a lot of resources on the wrong solution. Yet, in certain sectors such as banking, healthcare, or government services, waterfall might be preferable in order to mitigate risk.
Timeboxing fits into agile as a method of prioritization. With timeboxing, you keep your requirements slim and work within the constraints of the resources you have. You are willing to sacrifice features or requirements to protect resources.
The 3 key factors to execute timeboxing well
Eduardo Miranda of the Institute for Software Research at Carnegie Mellon, in the paper Time Boxing Planning: Buffered Moscow Rules highlights three key things timeboxing requires in order to be effective:
- The features or user requirements that make up the total delivery are grouped into functionally complete subsets;
- The subsets are prioritized so it is clear which requirements should be implemented first and which ones could be eliminated if there is not enough time to complete all of them; and
- Reasonable assurance is provided to the customer about the feasibility of a given subset within the imposed frame.
Okay, what do these three requirements mean?
Well, number one suggests that you have to put features together which need to be together. For example, if you're a software engineer building an app that has a login and an account, you need to build the database to store those accounts and the screen to allow someone to create an account. You also need to build the screen to allow someone to log into an existing account. You can't build one of these things individually and not build the others because when you come to launch the software, it will not be functional. So, at the end of the timeboxing exercise, there should be something functional; there should be the minimum viable product we mentioned earlier.
The second point talks about prioritization. For me, prioritization is absolutely the central point of timeboxing. With timeboxing, you are applying a real or arbitrary limit to the resources that can be applied to a problem or a task. To meet these time limits, you need to break the task down into its components, its constituent parts, and then you need to prioritize those so that you can deliver the maximum value you can within the resource or time constraints. So, number two basically tells us we need a really good prioritization system.
Number three depends on the circumstances in which someone is deploying timeboxing. It is assuming the software team is developing something for the product owner, who may be part of the same internal organization or maybe a separate external stakeholder. Good communication is required to make sure that the product owner or external stakeholder understands the process at play. Within an organization, technical or non-technical teams, this same principle remains; it is a principle connected with company culture.
Is it okay to ship something, software or non-software, that isn't 100% the best it can be?
This method and the agile philosophy suggest, yes, it is. But some companies have a company culture where that's not acceptable. They would rather spend more time and ship later in order to achieve maximum quality.
Other cultures, more startup cultures, will aim to ship and iterate and move quickly, prioritizing that above perfect output. So point three reminds us to communicate expectations and to align that with the culture of the workplace or organization that we are in.
Types of timeboxing prioritization variations to try
How do we approach prioritizing the constituent parts of a task, so that we can break it down and approach them one by one? Well, here’s a short list:
- In the Moscow Method each component is broken down into “Must have”, “Should have”, “Could have” or “Won’t have”.
- In Cumulative Voting (and it’s variant the Poker Technique) each stakeholder is given 100 points or dollars to assign to each feature or task. The stakeholders divide their 100 dollars by assigning a spending amount to each feature.
- In the Pairwise Comparison method you rank or choose from a group of alternatives by comparing them against each other in pairs, i.e. two alternatives at a time.
- In the Top Ten Requirements method you generate a list of ten components, tasks, or features from all requirements based on importance.
- In the RICE prioritization model you score and prioritize features based on reach, impact, confidence, and effort. You calculate a feature's RICE score by rating it on reach, impact, effort, and confidence in your ratings.
The Moscow Rules approach to timebox prioritization
The Moscow Rules method is a modified version of the original Moscow method. This modified version is presented by Eduardo Miranda in his 2011 paper. Miranda critiques other prioritization methods for being too arbitrary. For example, why is it the top 10 requirements? Why not top 11 or 12? Some projects may have less than 10 top needed requirements, some may have more. The use of that model feels arbitrary.
Miranda instead aims to redefine the Moscow categories away from the product owner's preferences for the final product which is achieved, and redefine them toward what the team can actually deliver. Miranda's adapted version of the Moscow Rules aims to improve the method of prioritization to maximize the ability to get stuff done and provide working functional software.
In Miranda's variation, 'must have' as a category is redefined to be a feature that is absolutely guaranteed to be completed in the timeframe. In the 'won't have' category, Miranda includes features for which there is no way they could fit into the scope of available resources. In doing this, he reshapes the central question from 'What do we want?' to 'What can we do?'
The pros of the Moscow Rules:
The benefit of Miranda's Moscow Rules is that you will ship more software, stick to budgets of time and resources, and get more done. This is the philosophy of focusing on what you can do and getting that done. This will result in higher productivity and perhaps those productivity gains will have knock-on impacts and cumulative benefits, meaning greater outcomes in the medium to long term, even if you're making certain short-term sacrifices.
The cons of the Moscow Rules:
The downsides here are fairly obvious in that this approach orients away from focusing on the value delivered to the end user. In that sense, does this really qualify as an agile project management technique if it isn't centered around rapid delivery of value?
How can I use timeboxing in my daily non-technical work?
If you're sitting here thinking, 'But Adam, I'm not a software developer working within an agile software development team,' then this might seem like a lot of not very useful information. However, the practice of timeboxing is not limited to agile methodologies or software. The benefits of timeboxing can be applied for workers of all types.
The basic principle is you take a big task and determine the maximum amount of time you are going to spend on it. You quickly break it down into all of its smaller components, hit the higher priority parts first, and get as much done as you can within the timeframe. Then you call it finished and pass it on. This won't work for everyone, and as we've said, it won't work for every company culture, but it can be a very effective tool if you're trying to move fast.
In the world of startups or tech, moving fast is one of the most important things you can do. So how can you deploy timeboxing for yourself or, on a larger scale, for your team? For yourself, it's simple. If you are already using time blocking, then this is a breeze. At Xembly, we all use time blocking every day. In the morning, our AI, Xena, messages me in Slack and tells me what I have on my calendar for that day. Xena asks me whether I want to add anything else to that calendar. I use the opportunity to block the amount of time I intend to spend on a task.
I try very hard to not work over that time, and to not work too much under that time. Over multiple days and weeks, it becomes clearer how much time something will take me so I can refine the size of the blocks I put on my calendar and the level of constraint I place upon myself. This is a hugely effective way of planning your work and managing your time, and I would recommend it to anyone.
On the level of a team, however, you can go a bit further and get more interesting.
I like to run my teams with the Scrum methodology. This is a form of team organization popular in agile and originally intended for technical teams. I redeploy it for non-technical teams, but basically everything in it is the same. At the beginning of a sprint, we determine who will do what work. Each of the tasks I assign to someone is given a points value, which determines how much time we think that task will take. We also add a second points value, which is the maximum points value, representing the maximum amount of time that should be spent on that task. That is timeboxing in practice. When you assign out tasks at the beginning of a sprint, you determine the maximum amount of time someone should spend on it, and they know to tailor their work and expectations to that.
If you’re using Xembly, then your timeboxing is a simple as chatting with Xena and blocking out that time. Xena will make sure that any meetings can be arranged around that, and will also automatically block other tasks in the remaining time.
Xembly turns AI time management into an AI chief of staff
Xembly is an AI chief of staff - scheduling meet ups, attending your meetings, recording the notes, creating action items, assigning tasks, and helping team members manage their time so that work gets done.
Here are three advantages of using Xembly:
Smooth AI scheduling
Xembly enables 1:1 appointments and complex multi-person scheduling requests with ease. Whether it's via email, Slack, or a dedicated scheduling link, Xembly's AI aide, Xena, coordinates the details for you and your participants.
Accurate meeting documentation
Xembly documents the essential aspects of your meetings, leaving out anything unnecessary. It provides notes, recordings, and compiles video snippets of important segments. Whether meetings are remote, hybrid, or in-person, Xembly helps you focus on meaningful conversations.
Intelligent task oversight
Xembly’s Task Manager gives direction to your calendar through its auto-task monitoring and time allocation. With Xembly’s Task Manager, users experience a 26% uptick in task completion rates. It creates time for meeting tasks and shapes your timetable to help you get them done.
If you're still not sold, check out our happy customers:
Try Xembly now by clicking here.
