FAQS‎ > ‎

Sizing and Flow Rate

Sizing and Flow Rate are interlinked so I will explain both together.

Sizing

Size is measured in man days, and you only ever size a story or feature in retrospect. How it works is this: Once a story is complete you look at how many developers worked on it for how many days and you mark that on the completed story. Once a feature is completed you add up all the stories that contributed to that feature and that was the size of the feature. You now have a way to do relative estimating because of the completed stories and features that now have a size on them.

Why go back to man days? Because it is the simplest thing and there are no arguments or questions around "What is a story point?" You have a consistent measure across the entire tribe that is easy to understand.

Flow Rate

Flow Rate is a simple calculation - the sum of man days on completed stories in the last iteration. You may want to also express an average flow rate and take the average over the last x iterations as a better indicator to avoid fluctuations. Remember, only feature stories get sized. If refactoring, bug fixes, component work happens - it doesn't get sized. They are part of the overhead of the project. This is another reason to take flow rate as a average over a number of iterations.

I have purposefully not used the word Velocity for this concept but for simplicity sake you may think of Flow Rate to mean the same as Extreme Programming's concept of *Velocity.

There are two reasons I don't want to use the word velocity in FAST
  1. In physics (where the term velocity comes from), Velocity has a direction component (vector) and a speed component. I have never seen a notion of direction used when talking about completed stories.
  2. Too many agile teams have been burned for too long with the words "increase velocity" - like it is something that a team can control. The fact is, you can't control velocity, you can only measure it. "Flow Rate" lends itself better to this purpose I feel. It also suggests that should an organization wish to increase the flow rate, then changes to infrastructure need to be made. Typically, these changes are neither cheap nor result in instantaneous increases. (Developers are NOT fungible assets!) See section on Getting Started and Scaling for the correct way to grow a team.

*Aside - Many people don't realize that Scrum borrowed the terms/concepts of Velocity and Stories from Extreme Programming. Neither of these terms exist in the Scrum Guide but have become a common practice amongst most scrum implementations.

Release Planning

Again FAST is looking to move away from heavyweight to lightweight. You can calculate when your release is going to be finished by dividing the Sum total of all Features divided by average flow rate. This gives you the number of iterations to estimated completion. No need for heavy and expensive 2-3 day release planning events.


I'm sure you still have many questions like, how do you handle bugs, annual performance reviews etc. For these answers head over the FAQ section.