On Tuesday, we looked at a simple idea: a new Sprint does not erase the history of work already in progress.
So what can that history tell us?
Velocity shows how much estimated work a team completed in previous Sprints. Throughput counts the items completed over a period. Both tell us about finished work, but neither tells us how long a particular unfinished item has been in progress or has been waiting.
Continue reading What the age of unfinished work can tell usPreviously, I argued that Scrum events create coherence, not control.
This is where that idea becomes practical.
Because there are moments in team life when speed is not the real problem. The real problem is loss of rhythm.
The team is busy. Work is moving. People are under pressure. But the usual patterns that help everyone stay aligned have started to break down.
Conversations become reactive.
Priorities shift too often.
Decisions happen too late or in the wrong place.
In those moments, trying to speed up usually makes things worse.
What helps is restoring rhythm.
Continue reading When rhythm matters more than velocityVelocity is one of those ideas in Agile that sounds more reliable than it usually turns out to be.
When I first encountered Agile, estimation felt like a breakthrough. If a team could size work consistently, and track how many points it completed in a sprint, surely planning would become more realistic.
In theory, that makes sense.
A team estimates work in story points based on effort, complexity and uncertainty. Over time, it learns its velocity: how many points it tends to complete in a sprint. That should help it plan future sprints with more confidence.
Continue reading Does agile velocity actually help?A tweet from John Cutler has been challenging me recently:
Instead of focusing on making ‘better’ estimates, focus on:
Your estimates will improve.
Why?
Continue reading Instead of focusing on better estimates…
Velocity is an important tool in Agile. Let me explain a little about what it is and why we find it useful.
One of the challenges when planning each two weeks’ sprint is working out how much work we can realistically commit to. That’s where estimates and velocity work together.
Since we estimate each task (using ideal hours), at the end of each sprint we can count up the values of all the tasks that we completed (only those that landed safely in the DONE column in Trello—that is tasks that have been both completed and successfully tested) to reveal our velocity for that sprint: how much value we were able to deliver to the project (or projects) during that two weeks’ timebox.
In theory that should then tell us how much we ought to expect to complete during the next sprint.
But it doesn’t always work like that.
Continue reading Velocity and why it’s important
