Getting the people to use story points in agile estimation is easy. Making them not to think in hours is tough.
I’ve been struggling a bit on how to get people detach story points from time. Attending the Professional Scrum Developer class by Richard Hundhausen helped me think of ways on how to explain this.
The important keywords I got from Richard’s class are size and complexity. Story points should be a measure of size or complexity. There is a correlation between complexity/size with time but we can’t really say exactly how long it will take to complete something but only that a simple thing takes a shorter time compared to a complex thing. There are a lot of reasons that affect this i.e. familiarity with the system, the component or even the people building it. This is why we should use the empirical nature of Scrum to discover this.
Here’s one idea I came up with.
Which do you think will take you longer to complete?
a. 5km marathon
b. 10km marathon
Answer: b 😊
How many hours will it take you to complete a 5km marathon? 10km
1. Duh … I don’t run marathon
2. My best time is x hours
3. Won’t know until I tried it
Using exact distance makes it easy to answer the first question. We know the farther the run the longer it takes to complete it.
The second question is a bit difficult to answer. There are a number of considerations
1. If you haven’t done it, you can’t really know. You may attempt to guess but it will most likely be off.
2. 10km run does not equate to 2x the time to run the 5km.
3. Even if you run the marathon, you know that each time you run it is a different story. You will tend to improve your time overall as you run more but the actuals are not always the same.
Based on the discussion above, I will relate the km distance to size or complexity and the run time as effort in hours.
There are a lot of unknowns in building software and doing it as a team adds to the unknowns. The answer is to try it out and discover your team’s velocity. The longer you build and keep the team together, you will expect your velocity to improve over time.
Velocity is the number of story points a team completes in a sprint. This value changes as you add/remove people to the team, update the definition of done, team’s familiarity with the system and its members etc. Velocity is expected to increase as you do more sprints (assuming you keep the team together). If you are interested to know how many hours it took for a story point to complete in a sprint, you can divide total capacity (in hours) by the number of story points completed. This by no means constant across different sprints but is a good input as you plan for the next sprint especially if you consider the historical data in the previous sprints.
Posted from WordPress for Windows Phone
One of the first challenges in Scrum adoption is to explain to your boss with a waterfall project management background what Scrum is all about.
He is probably not at all interested in what it is. He just needs his metrics.
Project management has deteriorated to a point where we manage the metrics rather than the project. Furthermore, the typical practices of waterfall projects like senselessly adding more people, compromising quality, change request process crippling product functionality makes the situation worse.
I still believe though that true project management is about the art of balancing the resource triangle variables (schedule, cost, scope, quality). The Scrum rules has “simplified” the balancing act by letting you adjust a single variable – scope. Time or schedule is fixed (a sprint is time boxed max. 4 weeks), cost is fixed (the development team size is fixed within the sprint), quality is not to be compromised.
In other words, Scrum just defines a framework where you set the cost, schedule, quality to a fixed value at the start of an iteration leaving the scope variable as the focal point of adjustment.
I suggest the following approach explaining what Scrum is to your (waterfall PM) boss:
1. Make sure your boss understands the resource triangle. Give hints before the actual discussion so he can research/recall what the art of project management is all about. You wouldn’t want to lecture him on this.
2. Explain Scrum as a framework that allows one only to tweak the scope variable.
3. Hopefully this gives him enough context to enable him to understand Scrum as you detail out the rules of Scrum.
1. Resource Triangle/Project Management Triangle (http://en.wikipedia.org/wiki/Project_triangle)
2. Scrum guide http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf
Posted from WordPress for Windows Phone
Mica covered how a systematic adoption of the different VS ALM tools helped make her team build quality software in an efficient manner.
Jeff showed off the different VS tools and their paractical use.
Rhea shared her experience in learning Scrum and making it work with a team who is only experienced in waterfall. She also showed the new VS 2012 tooling that can help new Scrum adopters.
Most important of all were the attendees. From the 83 that registered only 25 (mostly IT professionals) made it but I considered it a success and maybe the smaller group was a factor. It was a very interactive session where people were not only asking questions related to what they were actually doing at work but they also shared their actual experiences and insights. It was a gathering of practioners discussing all aspects of ALM – people, process and tools.
Thank you to all the speakers and attendees! Thank you Microsoft Philippines DPE for sponsoring the event!
I will be speaking in an event in Cebu TechTalk: Microsoft Visual Studio 2012 ALM. Register here if you are interested. There are 11 slots left! C u in Cebu 😉