(Thanks to George Dinwiddie for inspiring me to finish this post, which had languished for several weeks!)
Simplicity is a core tenet of Agile Software Development. The 10th principle of the Agile Manifesto has to do with Simplicity:
Most people with whom I've worked assume that simplicity is to be applied to the actual architecture & code of the software itself. That's absolutely true but as a principle and value, simplicity needs to be extended to the process as well.
For example, I've dealt with many teams who, during Sprint Planning, will spend anywhere from 10 minutes to an hour calculating the team's capacity in person-hours. They try to factor in every possible contingency to ensure that the number is as accurate and precise as possible. For a team new to Agile, this makes sense - if you haven't been used to delivering something every couple of weeks, you need to at the very least enumerate all of the things that teams members do that uses their time.
However, after the first sprint the team will have one very powerful data point - the amount of work that was completed to that team's definition of done. Regardless of the unit of measure used for the backlog items, e.g. Story Points, that amount of work is fundamentally more accurate than any predictive calculation.
My experience, and that of many other coaches, has been that a team will be slower in their first sprint than in any other. That's fine - the process is new and the team members need to get used to a new estimation process, etc. After 2 to 4 sprints, though, the velocity stabilizes. For most teams I've encountered, if you took the average velocity of sprints 2 to 4 you would have a very close approximation of their long term velocity, barring changes to the team.
So, the amount of time and effort spent during Sprint Planning to determine the team's capacity and how much work they can pull from the backlog quickly becomes wasteful. They could simply use the technique from XP, coined by Martin Fowler, called Yesterday's Weather:
If you didn't complete any work to the done state in the previous sprint, which does occasionally happen, you can either use the velocity of the last sprint in which work was completed or use a historical average of velocity. That may bump up the planning time to a minute.
Regardless, once a team has completed a couple of sprints determining capacity and pulling the appropriate amount of work from the backlog according to that capacity shouldn't take any more than 1 minute... hell, I'll be generous and give you 2 minutes.
I'm serious. It's that simple.
Simplicity is a core tenet of Agile Software Development. The 10th principle of the Agile Manifesto has to do with Simplicity:
Simplicity--the art of maximizing the amount of work not done--is essential.Simplicity is a core value of Extreme Programming:
Simplicity: We will do what is needed and asked for, but no more. This will maximize the value created for the investment made to date. We will take small simple steps to our goal and mitigate failures as they happen. We will create something we are proud of and maintain it long term for reasonable costs.Scrum was born out of the need to simplify heavyweight processes that didn't work:
Scrum, a scalable, team-based “All-at-Once” model, was motivated by the Japanese approach to team-based new product development combined with simple rules to enhance team self-organization.Lean Software Development also supports the notion of simplicity. In Mary & Tom Poppendieck's seminal book Lean Software Development, the words "simple", "simplicity" and "simplify" appear 76 times (thanks Kindle!).
Most people with whom I've worked assume that simplicity is to be applied to the actual architecture & code of the software itself. That's absolutely true but as a principle and value, simplicity needs to be extended to the process as well.
For example, I've dealt with many teams who, during Sprint Planning, will spend anywhere from 10 minutes to an hour calculating the team's capacity in person-hours. They try to factor in every possible contingency to ensure that the number is as accurate and precise as possible. For a team new to Agile, this makes sense - if you haven't been used to delivering something every couple of weeks, you need to at the very least enumerate all of the things that teams members do that uses their time.
However, after the first sprint the team will have one very powerful data point - the amount of work that was completed to that team's definition of done. Regardless of the unit of measure used for the backlog items, e.g. Story Points, that amount of work is fundamentally more accurate than any predictive calculation.
My experience, and that of many other coaches, has been that a team will be slower in their first sprint than in any other. That's fine - the process is new and the team members need to get used to a new estimation process, etc. After 2 to 4 sprints, though, the velocity stabilizes. For most teams I've encountered, if you took the average velocity of sprints 2 to 4 you would have a very close approximation of their long term velocity, barring changes to the team.
So, the amount of time and effort spent during Sprint Planning to determine the team's capacity and how much work they can pull from the backlog quickly becomes wasteful. They could simply use the technique from XP, coined by Martin Fowler, called Yesterday's Weather:
This is the principle that says you'll get as much done today as you got done yesterday. In iterative projects it says that you should plan to do as much this iteration as you did last iteration.Martin goes on to say:
I remembered a story I think I might have read while at school.
Some country decides to build a sophisticated computer system to predict the weather. After spending more money than I can imagine, they come up with a wonderful result - and proudly claim that the system is 70% accurate. Somebody then figures out that in this country if you predict today's weather will be the same as yesterday's weather you will be 69.5% accurate.
The point of course is that while Yesterdays Weather is a crude mechanism, it ends up being not significantly less accurate than more sophisticated (i.e. complicated) ways of doing it.So, by simply using the velocity from the last sprint you can determine how much work the team should pull for the current sprint in about, oh, 5 seconds. If there are going to be significant disruptions to the team, such as people taking vacations, etc., then you can factor that in. That should increase the amount of planning time to about 30 seconds.
If you didn't complete any work to the done state in the previous sprint, which does occasionally happen, you can either use the velocity of the last sprint in which work was completed or use a historical average of velocity. That may bump up the planning time to a minute.
Regardless, once a team has completed a couple of sprints determining capacity and pulling the appropriate amount of work from the backlog according to that capacity shouldn't take any more than 1 minute... hell, I'll be generous and give you 2 minutes.
I'm serious. It's that simple.
Comments
(http://thequickword.wordpress.com/2014/01/23/on-the-origin-of-the-modern-neckbeard-hacker/)
:-)