Sarah asked the team during Stand-up if she could pull in the other slice of the sorting widget she had been working upon.
The team looked at their board - everyone agreed they would have all the stories done by the end of the sprint and no one needed Sarah's help so that would be a good plan of action.
Working toward TINY is the key to increasing Velocity
How do you increase your Velocity? It's not by planning to do more work! It is by finishing more work - FIRST!
I delight in a team that proves their capability before they plan upon that capability.
Let the action preceded the planning, such that we are planning upon a strong knowledge of success.
When beginning teams wish to become high performing many mistakenly feel that getting work started earlier is the secret - it is actually the opposite of starting more work. There is a lot of learning involved in finishing work. This is where the high-performing team differentiates itself from other teams. High-performing teams finish lots of work, they know when the work is done and don't have to worry about polishing the edges.
It is sometimes true that if the team is not finishing their work well - that the problem exists up-stream of the work. Typically in the intake of that work. Perhaps starting work earlier upon the story would help this particular effort - at the expense of something else - yes. Yet, the simplest thing would be to make this story smaller (there must be 100 ways to slice a story). And then if we finish it, bring in more work when it is done. Perhaps another small story - a slice of something similar.
The smaller the stories the easier it will be to finish them.
There are countless techniques to help teams complete lots of work. For example - have you tried to write the acceptance criteria of the story in an executable style language (DSL) that can be run when the developer thinks they have succeeded in solving the problem. Using Behavior Driven Design techniques and a ubiquitous language from the product visionaries down to the implementors and testers greatly reduces the complexity of producing value for customers. Using these techniques one moves complexity into the domain of the system expert and gives them tools to simplify the development of features - creating smaller stories - moving toward tiny on the effort scale.
See Also:
What is an Agile Transition Guide?
The team looked at their board - everyone agreed they would have all the stories done by the end of the sprint and no one needed Sarah's help so that would be a good plan of action.
Working toward TINY is the key to increasing Velocity
How do you increase your Velocity? It's not by planning to do more work! It is by finishing more work - FIRST!
I delight in a team that proves their capability before they plan upon that capability.
Let the action preceded the planning, such that we are planning upon a strong knowledge of success.
When beginning teams wish to become high performing many mistakenly feel that getting work started earlier is the secret - it is actually the opposite of starting more work. There is a lot of learning involved in finishing work. This is where the high-performing team differentiates itself from other teams. High-performing teams finish lots of work, they know when the work is done and don't have to worry about polishing the edges.
It is sometimes true that if the team is not finishing their work well - that the problem exists up-stream of the work. Typically in the intake of that work. Perhaps starting work earlier upon the story would help this particular effort - at the expense of something else - yes. Yet, the simplest thing would be to make this story smaller (there must be 100 ways to slice a story). And then if we finish it, bring in more work when it is done. Perhaps another small story - a slice of something similar.
The smaller the stories the easier it will be to finish them.
There are countless techniques to help teams complete lots of work. For example - have you tried to write the acceptance criteria of the story in an executable style language (DSL) that can be run when the developer thinks they have succeeded in solving the problem. Using Behavior Driven Design techniques and a ubiquitous language from the product visionaries down to the implementors and testers greatly reduces the complexity of producing value for customers. Using these techniques one moves complexity into the domain of the system expert and gives them tools to simplify the development of features - creating smaller stories - moving toward tiny on the effort scale.
See Also:
What is an Agile Transition Guide?
Comments