Hi, we’re Tektonic Labs … a small software company with lots of ambition and great ideas about how we can produce awesome products for our customers.  This series of articles describes how we use Scrum to deliver software projects on time and on budget. 

We use Lean Agile principles for the management of workflow, with the following aims;

1. To make work visible – real-time and up to date
2. Limit work-in-progress (WIP) – through planning and monitoring team Velocity
3. Measure and manage workflow – through Story points and Velocity
4. Prioritise work effectively – through clear priority settings
5. Continually improve and adjust work practices

In this article we’ll walk you through how we Measure & Manage Workflow.

Focus on the right work & standardise it

Work is the stuff we do to make things happen. We turn up in the morning, boot up our devices and log in to the (sometimes) myriad systems we need to use. We check our (sometimes) huge amount of emails and start doing stuff.  But the problem is … often the stuff we do is not the stuff we should be doing.

As Peter Drucker says … “there is nothing so useless as doing efficiently that which should not be done at all.”

In Lean thinking, we apply the concept of Value as defined by the customer, and we identify those tasks we do that add value (we call these Value Adding) and those that don’t (called Non-Value Adding). The stuff that adds value are the things we should be doing, and the stuff that doesn’t add value should be minimised (sometimes they’re necessary) or eliminated.

At Tektonic Labs we focus on delivering value as defined by our clients through;

1. creating and maintaining standards for how we do our work
2. applying these standards in a disciplined way
3. monitoring the performance of our work
4. being ruthless in minimising and eliminating non-value adding activities.

Measure what the customer wants

Our clients want their software projects delivered on time and on budget. Of course, they also want the software to perform, so our definition of “delivered” implies we have achieved the performance standards our client wants. Nothing we do is “Done” until it works. So, our client is measuring our performance against 3 things – Time, Money, Performance.

The trick is, to create software it’s very difficult to use time, money and performance as input measures for forecasting. Time is easy enough to measure, but it can be very misleading to forecast how long a task will take without taking into account the degree of difficulty of that task. Money is typically a function of time, and performance of software can only be accurately measured when a task is completed.

Scrum is an elegant project management concept based on a simple approach. We use Sprints, User Stories, Story Points and Velocity as the means of measuring our project inputs to deliver what our client wants.

We break each project down into small units of work (called Sprints) and deliver working software at the end of each Sprint (remembering our definition of “Done”). Each Sprint is made up of a collection of Stories, and each Story is assigned Story Points. These Story Points reflect the estimated “effort” required for the whole team to move a Story from the “To Do” pile to the “Done” pile.

Breaking a large project down into bite sized chunks allows us to focus on the small amount of work at hand, do it well, make it perform, and then move on to the next small chunk. In this way we iterate our way to the end of the project.

At the start of each project we create the list of all the User Stories (called a Backlog) and each User Story is assigned a Story Point estimate. From this we can estimate how long a project will take to deliver in full within a forecast range of values based on our team’s past Velocity (the number of Story Points the team can execute in a 2week Sprint).

Monitor how we deliver on that

As the project evolves and our estimating accuracy increases, our forecast for “delivered on time and on budget” becomes more and more precise. As our team becomes more familiar with the project, our Velocity will become more consistent, allowing us to forecast with more accuracy and precision.

The one thing we must do (and this is where applying disciplined standards is so important) is estimate our Story Points consistently. And we do this using Planning Poker, a fun game-based scoring platform that allows the team to score each User Story, compare scores, resolve differences and lock in scores in Jira.

At the end of each Sprint we conduct a retrospective meeting and review the actual velocity against the forecast velocity. We review our Story Point accuracy and take that into future Sprints through the adjustment of our Velocity forecast. We don’t re-estimate Story Points.

For example, if our last Sprint consisted of 46 Story Points, but we haven’t completed 2 User Stories of 3 points each, then we might reconsider our next Sprint and only take on 40 Story Points instead of 46, and of the 40 points in the next Sprint, we would bring in only 34 points worth of new User Stories because we still need to complete the 2 User Stories rolled over from the last Sprint.

Manage our workflow to deliver client value

By adopting Scrum, Agile and Lean principles, we are able to manage our workflow in a disciplined and predictable way and deliver what our clients want – working software on time and on budget.

References and further reading

DeGrandis, D. (2017), Making work visible, Amazon

Brophy, A. (2013), Guide to Lean, Financial Times

Womack, J. and Jones, D. (2003), Lean Thinking, Free Press

https://www.atlassian.com/agile/scrum

Cohn, M. (2006), Agile planning & estimating, Addison-Wesley

The Agile Manifesto, agilemanifesto.org