The document discusses alternatives to using story points for estimating work in agile software development projects. It analyzes claims made about the benefits of story points and finds limited evidence to support these claims. The document proposes using the number of completed backlog items per sprint as a simpler and more efficient metric for planning, tracking progress, and estimating release dates. Correlation data from multiple projects shows story points and number of items completed tend to provide similar information about the amount of work done.
11. The Flat Earth Society (also known as the International Flat Earth Society or the International Flat Earth Research Society) is an organization that seeks to further the belief that the Earth is flat instead of an oblate spheroid More at : http://theflatearthsociety.org
14. (Hindsight is always twenty-twenty) -Anonymous (the other one!) Life Can only be understood backwards, but it must be lived forwards… - Soren Kierkegaard
22. The Data Correlation: 0,755 Team A / Company N Team HC / Company N Correlation (w/out) normalization: 0,83 Correlation (w/out normalization): 0,92 Team CB / Company N Team CF / Company N Correlation: 0,51 (0,71 without the spr14) !!
23. The Data Team HCM / Company N Correlation (w/out normalization): 0,88 Correlation = 0,86 Team A / Company JO Correlation: 0,70 Team 2 / Company RF Correlation: 0,75 Team 1 / Company RF
33. Sprint x Evolution of velocity Start of pilot/beta Release date Start of pilot/beta Actual progress trend What progress trend should be What progress trend should be
35. The Velocity Bet Their history stated the following velocity evolution in the last 3 sprints: 1 8 8 They were learning the product and area in the first few sprints, which allowed for a ”getting-up-to-speed” assumption. Additionally they had committed to 15 items in the Sprint planning meeting. The product Owner stated that the R&D team would start doing 15 items per sprint (which would help them meet the goal of releasing the pilot and the release on time.) What was the result after the sprint?
36. Sprint x + 2 They did 10 items. A 20% increase in velocity.
42. Vasco Duarte @duarte_vasco http://bit.ly/vasco_blog Joseph Pelrine @josephpelrine http://metaprog.com/blogs
Notas do Editor
Blog:185 on 18.01.2012 Slideshare: 48 on 18.01.2012
I used to live in a warm, sunny place: Portugal but…
… for some reason (which I don’t understand yet) I decided to move to Finalnd :O)
Galileo started by asking questions about what he saw...
Just like we should...
We’ve all been exposed to various estimation techniques. Just quickly: can you name a few? Expert estimation Consensus estimation Other complex estimation techniques like: Gantt, PERT, Function Point Analysis. Then we have cost vs time with cost techniques like: COCOMO, SDM, etc. And of course, the topic for today: Story Point Estimation. What do all of these have in common? They all look at the future. Why is this important?
Because looking at the future is always difficult. We humans are very good at anticipating immediate events in the physical world, but in the software world what we estimate is neither immediate, nor does it follow any physical laws that we intuitively understand! The indisputed fact is that we, humans are very bad at predicting the future. But that is not all! Lately and especially in the agile field we have been finding a new field of study: Complexity Sciences.
Retrospective Coherence... Fibonnaci series as an example of this
A field of study that tries to identify rules that help us navigate a world where even causality (cause and effect) are challenged. An example may be what you may have heard of: the Butterfly effect... Complexity Sciences are helping us develop our own understanding of software development based on the theories developed in the last few years. Scrum being a perfect example of a method that has used complexity to inspire and justify its approach to many of the common problems we face in Software development. Scrum has used self-organization, and ”emergence” as concepts in explaining why it’s approach works. However, there’s a catch.
What do you think of when you read this word? This is just a simple example of something that Complexity Sciences explore. In a complex environment we don’t have discernable causality! Some times this is due to delayed effects from our actions, most often it is so that we attribute causality to events in the past when in fact no cause-effect relationship exists (restrospective coherence). But, in the field of estimation this manifests itself in a different way. In order for us to be able to estimate we need to assume that causality exists (if I ask Tom for the code review, then Helen will be happy with my pro-activeness and give me a bonus). The fact is that in a complex environment, this basic assumption that we can assume causality is not valid! Without causality, the very basic assumption that justifies estimation falls flat! Cognitive ping-pong to re-inforce the ”complexity” point.
So, which is it? Do we have a complex environment in software development or not? If we do then we cannot at the same time argue for estimation (and build a whole religion on it)! And, if we are not in a complex environment we cannot then claim that Scrum, with it’s focus on solving a problem in the complex domain, can work! So then, the question for us is: Can this Story Point based estimation be so important to the point that its creator now claims exhorbitant amounts of money to teach you what either does not work, of fully invalidates the method (scrum) which he will also happily sell you? Luckily we have a simple alternative that allows for the existence of a complex environment and solves the same problems that Story Points were designed (but failed to) solve.
Not everything scales Not everything scales equally Not everything scales linearly
The alternative to Story Point estimation is simple: Just count the number of Stories you have completed (done) in the previous iterations. They are the best indicator of future performance! Then use that information to project future progress. Basically, the best predictor of the future is your past performance! Can it really be that simple? To test this approach I looked at data from different projects and tried to answer a few simple questions
Here are the questions that I started with...
Exchange rate – how people transform SP’s into time (real – understandable)
Shelf-life and how long term estimates don’t work
This was a very important project for this company. They were suffering pressure in a market segment that was very important for the revenues, and they needed a good product with lots of features… Here’s how you should read this graph, let me go slow to make sure you all understand this…
Let’s quickly survey the room. How many items did that team complete in the third Sprint ? Why?
The final question is really: why do we really estimate stories in Story Points and have built an entire religion with ceremonies, sacrifices, priests and a pope of Story Point estimation? The fact is that we don’t release Story Points! When all is said and done the question that me or you as a customer will be interested in answering is: does this product have the ”story” that I am interested in?
Blog:185 on 18.01.2012 Slideshare: 48 on 18.01.2012