Does a Shorter Sprint Deliver More? –
Explained with Little’s Law
Using the principle of Little’s law, we take a look at sprint duration and how it can affect the time to market of a product.
Agile development methodology suggests sprints should be time boxed between 1 week and 4 weeks. Most agile leaders recommend smaller sprints and find that teams deliver more value with smaller sprint. While trying to understand the reason behind the benefit of small sprint, let us identify the reason with the help of Little’s law.
Little’s law states that in the average number of items (WIP) that stay in the system is the product of arrival rate of the items (T) and times item spends (CT) in the system.
Cycle Time (CT) = Work in Progress (WIP) / Throughput (T)
We can define each term from agile perspective:
- Cycle Time: Total elapsed time to move story from TO-DO state to DONE state.
- Work In Progress (WIP): Total number of user stories committed in the sprint.
- Throughput: Tasks completed by developers in unit time.
We can easily assume that faster we move stories from a TO-DO state to a DONE state, stories will be completed faster, and consequently more values will be delivered to end users. Moving stories faster from TO-DO state to DONE state, requires us to reduce the cycle time of stories.
As per above law, we need to either increase throughput or reduce WIP (sprint backlog) to reduce cycle time. Now in the real world, increasing throughput of developers in a short span of time is not an easy task. We may have to hire additional experienced developers, provide more training to teams, teams may have to stretch, and lot of other activities need to be done improve throughput. However, it has financial and personnel implication and such solution may not last longer.
Another option is to reduce WIP (sprint backlog). Sprint backlog is created based on estimation of stories and the velocity of the team. Consequently, reducing capacity of team is the only option to reduce cycle time. Now if we want to reduce capacity of team, we are left with only one option: decreasing the duration of the sprint. That means a shorter sprint is the only way to reduce the WIP items, which will cut cycle time and help us to move stories faster from a TO-DO state to a DONE state. That is shorter cycle time, which also means shorter sprint, reduces WIP and improve Go-To-Market for the customer.
Moreover, in mathematics term, cycle time and work in progress are directly proportional to each other. That means work in progress has direct impact on cycle time and reducing work in progress will ultimately reduce cycle time, given constant throughput.
We have seen that shorter sprint lowers the cycle time and also helps us to close stories faster. Shorter sprints help teams to commit less stories, which means that the team has fewer items to focus, which leads to less noise in the development cycle, less task switching, fewer dependencies and fewer unnecessary communications across teams and shores.