Christopher Frost

Blog

  • Ditch Deadlines: ‘Focus Lines’ Can Boost Productivity without Burnout

    In many workplaces, deadlines are set arbitrarily – plucked from thin air or driven by external pressures rather than careful consideration of the resources and scope. While the intention might be to create urgency, arbitrary deadlines can lead to rushed work, technical debt, and burnout. At the heart of the issue is a lack of transparency and clarity. Teams know that these deadlines aren’t grounded in reality, but they feel pressured to comply, fostering a culture of cutting corners and misaligned expectations. Instead of promoting productivity, arbitrary deadlines undermine trust and ultimately harm both morale and team performance.

    A more effective approach is to use Focus Lines – intentional, well-communicated time based milestone that guide effort without the rigidity of traditional deadlines. Unlike deadlines, Focus Lines don’t define success or failure. They serve as checkpoints for progress, encouraging teams to align around clear goals while allowing for flexibility and adaptation. The key difference lies in the mindset: Focus Lines highlight the importance progress and learning rather than racing toward an arbitrary, do or die, fixed date.

    Focus lines work because they leverage Parkinson’s Law – the idea that work expands to fill the time available. Without clear boundaries, projects can drift indefinitely. By setting Focus Lines, teams create honest constraints that drive momentum and prevent unnecessary overwork. However, because they are treated as a type of milestone, they provide enough breathing room to accommodate unexpected challenges. This results in better quality work and a healthier pace of delivery without the risk of team burnout and low moral.

    In practice, Focus Lines can be implemented by defining clear, time-boxed periods of effort, much like the concept of sprints in Scrum. A sprint acts like a recurring Focus Line – a regular interval that reminds the team to deliver value. Just as sprints drive consistent progress without arbitrary pressure, a Focus Line acts as an achievable milestone, promoting focused progress. By adopting this mindset, teams can foster a sustainable pace of work, ensuring they remain productive without sacrificing quality or well-being.

  • Little’s Law

    Little’s law was first published in 1954. It wasn’t proven true until 1961 and the proof was simplified in 1972. This just about pre-dates iterative development methods and certainly pre-dates the Agile manifesto (2001). It’s from the same period as Toyota’s production system which gave us several great concepts (thank you Mr Ohno). Unlike these others, Little’s law is not very well known, but it is at work every day on your Jira boards. So what is it?

    Let’s start with some notions you might already be familiar with. These are measures or metrics we encounter in our work.

    Lead time

    The average time it takes new items of work to enter and then leave the system. Items of work can be issues or stories from a work tracking tool (e.g. Jira). What counts as entering and leaving the system is ambiguous but the important thing is to be consistent. Decide when a work item is “started” and when it’s “done” (or cancelled), and make sure it’s automatically measurable.

    Including everything in the backlog has some interesting and potentially positive consequences. How long do issues or stories sit in your squads backlog before moving to a sprint or being marked as “won’t do”? If “started” is defined as when an item of work moves in to a sprint then you may want a separate definition of Lead time for items in the backlog.

    It should be noted that Cycle time, Takt Time and Wait time are other metrics that are often used when describing systems of work, while we don’t discuss them here it’s important to know that they are not the same as Lead time.

    Throughput

    Throughput is items of work done per period of time. To put it another way, Throughput is the average delivery rate and could be expressed as, for example, 3 items a week. It might take most of the week to do one of the items and then only a few hours for the other 2 items of work. Little’s law doesn’t care about variability, just the average.

    WIP (Work in progress)

    Number of items of work in the system. The definition of being in the system must be the same as the one used for Lead Time. If the clock is ticking for items in the backlog then those items count towards the WIP total as well. Little’s law assumes that new items of work are arriving at the same rate that they being done (this is a property of something called a stationary process). In reality this is unlikely to be true but you can take the average over the same period of time used to calculate the Throughput.

    So with those terms defined, what is Little’s law.

    Lead Time = WIP/Throughput

    It’s important to remember that these are all average values. In most cases some items of work will be high priority and shoot though the system more quickly, this won’t effect the averages. The other constraint is that any work items that enter the system must be counted as leaving the system even if they are cancelled. If they are not counted then the values for Work In Progress and Throughput will become increasingly incorrect. The more variation in the values used, the lower the accuracy of the metric being calculated.

    We can now use Little’s Law to indicate that increasing the amount of Work In Progress has the effect of increasing the Lead time for each new work item to be completed.

    Examples

    If there are 100 items in progress (the backlog and the current sprint) and the Throughput is on average 20 items a week (for a 5 day week) then the Lead time for new items will be 5 weeks. This assumes new items of work are arriving at a steady rate, equal to the Throughput. If new items are arriving at a faster or slower rate then the Work In Progress count will gradually change and the Lead time will increase or decrease respectively for those new items.

    A high priority task can jump the queue and could be done more quickly but everything else sat in the queue will be delayed. Little’s law will be preserved.

    Let’s suppose a new feature comes along, an epic is created and 50 new work items enter the backlog. If the Throughput remains constant at 20 items a week, the Lead time for subsequent new items is going to increase to 7.5 weeks. Assuming the priorities mean no queue jumping, you will know when the last work item of the new feature is likely to be done.

    Story points

    Little’s law will continue to work even if you start to measure story points instead of work items. This potentially offers a big improvement as not all work items take an equal amount of time to complete. For a stable team that can point work items predictably, individual story points will take a similar amount of time to complete.

    Little’s law can handle the differences in work items (if there are enough of them) as it relies on averages but this means a lower accuracy for predictions. With meaningful story points, the accuracy of predictions can be improved.

    Leveraging Little’s Law

    If you read my last post on Leading and Lagging indicators then you should be able to identify that Lead time and Throughput are lagging indicators. They are easy to measure and quantify the current situation. Work in progress is the only leading indicator, it can be changed today and provides insight in to the future.

    It’s possible to prioritise an item of work and get it done quickly but that doesn’t affect the overall Lead time. Using Little’s law we know that we can reduce the overall Lead time by working on less stuff or increasing throughput. Which is easier, do you think?

  • Lies, Damn Lies and Metrics

    When working towards an objective or goal there are often some measurements taken to try to indicate progress. These indicator measurements (shortened to just metrics) will be either leading or lagging indicators and it’s important to understand the difference.

    Key Performance Indicators

    Indicators are statistical values to measure the current situation as well as attempting to predict trends and outcomes. A Key Performance Indicator is a measurable value that shows how effectively a company is achieving business objectives. Business objectives can vary from ROI (return on investment) and research, to reduction of incident rates, reduction of cost, and improvement of product fit.

    Use indicators that quantify the current situation and that provide insight into the future.

    • Lagging indicators quantify the current situation.
    • Leading indicators provide insight into the future.

    Lagging Indicators

    Lagging indicators are typically output oriented. They are easy to measure but hard to influence or improve. A lagging indicator measures something that follows an event. A lagging indicator is often used to confirm that a pattern is occurring.

    For example, many organizations have an objective to deliver some items of work on a specific release date. Number of items Delivered, is a clear lagging indicator that is easy to measure. A simple report from a work tracking tool (e.g. JIRA) will produce this. Achieving this objective in the future requires product release predictably. For product release predictably, there are several leading indicators.

    Lagging Indicators are things that might change in the future. A simple example is ones weight.

    Leading Indicators

    Leading indicators are easier to influence but harder to measure. They are harder because processes and tools need to be in place in order to measure them.

    Building a product (or larger features of a product) is not a known endeavour.  It’s the main reason why iterative development processes have proven superior to the waterfall process. It takes time for the level of effort and the technologies required to build the product to be understood. When changing priorities are also taken into account, the lagging indicator becomes an improbably difficult target to hit. Using a leading indicator lets you see if you’re moving in the right direction. It gives you a chance to make changes while there is still time.

    If product release predictably is required to deliver some items of work on a specific release date, what leading indicators can help. A backlog with only a few items ready to be worked on indicates a poor understanding of upcoming deliverables. Unstable velocity indicates a lack of measurable progress that can forecast a completion date. Number of ready work items and velocity stability are good leading indicators of product release predictably. They provide insight into future releases.

    Leading Indicators are things you can change today. Simple examples are portion size or calories consumed.

  • Product Owners and GDPR

    If you don’t know what the General Data Protection Regulations (GDPR) are then where have you been hiding. It’s responsible for the piles of email most people recently received about updated privacy policies and consent requests. Whatever you think of GDPR, it’s now law across the European Union (EU). If you are processing personal data it will probably apply to you, even if you are outside of the EU as it casts a very wide net. It may not be easy to enforce but GDPR covers the processing of personal data by any company in the EU and the personal data of EU citizens anywhere in the world. The point of this post isn’t to explain GDPR in general but to draw attention to Article 25.

    Data protection by design and by default

    If you are responsible for the features/requirements of a piece of software that processes personal data then you need to comply with the requirements of Article 25.

          “This means you have to integrate or ‘bake in’ data protection into your processing activities and business practices, from the design stage right through the lifecycle.”

    Where the processing activities are automated with software then also consider automating the various searches, updates and deletions required to comply with a persons rights under GDPR. Do you really want to be manually running queries against your database every time someone wants to know what data you hold on them? It’s important to think about all the places where personal data is held. The email server, backups of the database, any cloud providers such as mailing list services and what about that notebook you wrote something in about a customer last month.

          “Data protection by design is about considering data protection and privacy issues upfront in everything you do. It can help you ensure that you comply with the GDPRs fundamental principles and requirements, and forms part of the focus on accountability.”

    Whenever the processing of personal data is instigated or changed in a way that presents a new risk to the security of the personal data then a Data Protection Impact Assessment (DPIA) should be carried out. If a Data Protection Officer (DPO) is available, they will oversee and advise on the DPIA. This will guide you when considering how much security needs to be implemented in order to protect the personal data being processed. At the very least, you should include features in your product that allow for a persons rights to be honoured in a timely manor. When responding to requests about personal data you must respond without undue delay and at least within one month.

          “This concept is not new. Previously known as ‘privacy by design’, it has have always been part of data protection law. The key change with the GDPR is that it is now a legal requirement.”

    If you suffer a data breach it is very likely your supervisory authority (The ICO in the UK) will want to see evidence of compliance which includes data protection by design and by default. Would you be able to demonstrate this, can you point at work items from your product backlog that support data protection? Does your definition of “Done” include updating your records (and the DPO if available) whenever changes occur to the storage or processing of personal data? These are all things the supervisory authority are likely to take in to account when deciding if you did enough to protect the data, if not you could be liable for a massive fine.

    There is no need to become a GDPR expert, that responsibility lies with the DPO, but a little research or the one day GDPR foundation course can give you the knowledge you need to understand the terms and implications of GDPR. The ICO website has a GDPR section that’s an excellent place to start.

    All quotes take from the Information Commissioners Office under the Open Government Licence v3.0.

  • Technology On the Edge

    I’ve often used three phrases to describe the state of advancement of some piece of technology and recently realised that while two are well known the third is not. Most people have heard of “Cutting Edge” and “Bleeding Edge” but rarely “Beyond the Edge”. Here are my definitions of these terms, yours may differ but hopefully not too much.

    Cutting Edge

    I regard this to be the same as “State of the Art” and possibly the same as “Leading Edge” although there seems to be some debate about the latter. It is the best technology you can by off the shelf, available through retailers and comes with some form of support. In terms of software it should be considered the latest production ready release. This is technology for the mass market where it needs to just work. With this category of technology the reliability and ease of use is more important than the features it has or even the cost. The balance of features against cost must provide enough value for money, if not it isn’t ready for it’s intended market. It must wait for either the cost to come down or the features to improve. The only thing that isn’t negotiable is the reliability and easy of use.

    Bleeding Edge

    This category of technology should be considered more risky and/or harder to get hold of, it emphasises the increased risk, you might cut yourself on the edge. You’re going to have to work a little harder to get hold of it and to use it. You may even need extra domain specific knowledge to use it. This could be by getting a specialist company to put together something bespoke. It could involve building pre-release beta software that comes with caveats about it’s readiness or known bugs. Ease of use is still important but equally, or less so, than the cost and feature set. People will go for this category of technology to get some killer feature that is worth the risk or maybe just because they like to live life on the edge.

    Beyond the Edge

    Technology in this group goes even further than bleeding edge technology. Such is the risk of getting and using such technology, you have literally gone off the edge and have nothing to stand on if it goes wrong. It will probably involve putting time and money in to creating something new and novel that has never existed before. Your options for getting it will likely be limited to a small set of companies or people that are advancing what is possible with a specific technology and pushing the edge forward. Domain specific knowledge is almost certainly required. At this level the ease of use and reliability are entirely secondary to the feature set, such risk or cost wouldn’t be acceptable if there wasn’t some new ability you get that makes it worth while.

    I find this to be a nice way to categorise technology, the importance of reliability and ease of use diminishes as the importance of a specific feature (or group of features) increases. As this happens the risks associated with obtaining and using the tech also increase. While the phrases “Cutting Edge” and “Bleeding Edge” are well documented I don’t know where the phrase “Beyond the Edge” comes from. If you happen to know please leave a comment.

  • Estimating Stories

    There are several approaches to software development that require the estimation of work items, many of these approaches call work items, stories or tasks. To keep this post applicable to various approaches I’ll simply refer to work items. There are many approaches and guides about how to do estimating, the process, the range of values (Fibonacci, linear etc…) but they all seem to have different ideas about the unit of estimation.

    The whole point of the exercise is to provide an estimate of when the team will be able to delivery feature x or release y. How long will all the work items between now and the desired release take. An initial attempt was to use time as an estimating value, allowing the list of work items to be added up to get the answer. This has been proven not to work. Firstly it’s subjective, the time it will take one person on the team to do the work will be different to another team member. Secondly, humans are really bad at estimating the time required for anything other than simple or well understood tasks.

    To address these two problems we need something that is easier to reason about and something that applies to a work item regardless of who works on it. Several options have been proposed such as the customer value of the work, it’s difficulty, or keeping it entirely abstract with no unit of measure at all. I advocate for using complexity (or inversely simplicity) to estimate work items.

    Let me justify this. Complexity is an arbitrary measure of the mental overhead, the number of cross cutting concerns or just how tangled up the work is. There is no need to define a discrete unit of complexity, it’s enough to provides a scale. A complex work item could be easy for an individual developer, if they have lots of prior knowledge about it. So if complex isn’t the same as hard, then Simple != Easy. This is why using the difficulty (or easiness) of a work item is flawed, it involves an individual, it’s subjective. Points are an estimate for the team, not an individual. The complexity of an item is constant, it may be poorly understood before the work is started but the actual complexity will be unchanged after the work is done.

    Once this approach has been used to estimate a few items the team should start to develop a shared consensus of how complex a work item is relative to other items that have already been estimated. Having a discrete scale that needs to be worked out for each work item is time consuming and unnecessary. Getting a consensus on the relative complexity of a work item is quicker and promotes discussion about the work item that leads to a consensus understanding of the work item rather than some metric about it.

    Knowing how many complexity points need to be completed for a release isn’t enough though. Once a team has completed a few (hopefully short) iterations that have been estimated by complexity they will have an idea of the their pace. A teams pace (a.k.a. velocity) is a measure of how much complexity can they get through per iteration. Now the team can use their pace to predict when they will reach a particular release or feature. This places an emphasis on a stable pace rather than the fast pace, a stable pace means more reliable predictions of release dates.

    There are many opinions about how this should be done and I don’t think the software development community has come to a consensus on this area yet. My view is certainly not exhaustive and I’m sure there are conflicting views out there but hopefully my reasoning has been at least a little compelling.