through the eyes of a non engineer

if we take an assembly line into account done means the product or the individual part is finished. no further action needed other than maybe the hand off to the next stage. but to get a sense of throughput (velocity) we measure what gets done in a given amount of time. in most of the software task management tools done = closed. so in order to predict an eta of a certain release, why don’t take the sum of all closed and accumulate? before closed there can be, depending on your workflow, several statuses that dosen’t necessarily mean coding anymore. like qa, review, merge you name it. all these statuses have the power to send something back to open. not browser compatible, missed acceptance criteria, merge conflicts. so adding the numbers from qa, review and merge to the actual closed ones b/c they are “almost done” is window dressing or cheating if you will and pareto doesn’t like you anymore. because if we just focus on the done or closed state and not talking about “almost done” than there is no such thing as done done.

so this one goes out to all the POs out there, if the average velocity is x you can not expect x + 10. period. you’ll spend time in you sprint planning on things that will most likely not even get touched. waste. you will increase the number of items to focus on within a sprint so the tendency of multi tasking will increase. waste. and the worst part is that your team knows at the beginning of the sprint that they will not achieve the goal. or they tend to lower writing tests or testing in genreal which will increase technical dept. waste. dear POs, you can not put more paper in a printer and expect faster printing.      

I assume there will be posts about: me talking to POs, me talking to VPs, me talking to engineers, me talking to myself. did I forget QA? how inconsiderate but stereotype.