What are different way to size stories? Why do we do story points, not hours? February 1, 2009
Posted by editor in Agile Practices, Scrum.1 comment so far
ike Cohn talks a lot about this in his book Agile Estimation and Planning. You can use any measure to size stories.
Teams use different sizing techniques
T Shirt Sizing
X Small, Small , Medium , Large , Xtra Large
or
Coffee Sizing
Small, Tall, Grande
You can pick any sizing technique. Make up one if needed.
This is mainly done as we as humans and as managers are better at abstract terms. If we use hours as a way to size stories,then the managers in the room have questions, teams dont immediately feel comfortable with hours.
Sizing keeps the planning meeting at a fast pace.
A general measure you can use for T Shirt sizing is how many days it take to complete a story
Small story – 1-3 days
Medium – 3- 5 days
Large – 5 – 7 days
X Large > 10 days
In order to convert a story size to a number you can use either factorial, Fibonacci or Squares.
Sizing Techniques
If in a sprint your team does two small stories and two medium then your velocity is 9 * 2 + 4 * 2 = 26 ( if you are following the squares techique). Square is simple and works quite well.
How does Scrum work on large complex stories? We cant do this in a month? February 1, 2009
Posted by editor in Agile Practices, Scrum, XP Practices.add a comment
The word potentially shippable does not mean that you ship to production every Sprint in Scrum
You can have stories that span multiple sprints, that may not make it to production. This may be part of a larger EPIC story. The goal is to work on it every sprint. We have seen many instances where the product owner decided to ship the story half way through that process, as they see see that what is developed so far is not complete, but is good enough to ship.
How do estimate on something you know nothing about? February 1, 2009
Posted by editor in Agile Practices.add a comment
You can use what is called as Spike. This is not a Scrum specific word. If your product owners asks you to build a robot and you are a software developer who has never done that , then it is obvious that you will not be comfortable giving a sizing or estimate on that story. Instead you can write a story called a Spike. This is a real story that your team will work on .
The intent of the story is to understand the actual story better Example: Investigate a build vs buy option Write some code that gives you enough confidence to understand the complexity involved in building a robot. Compare options example you may write some code to compare different OR mapping layers like Stored procedure, Hibernate , Object databases etc In the end estimation is always a guess. You can never be perfect You will get better at it as your team works together on that domain for a a while.
How can I manage my time between working in this team and other day to day activities? February 1, 2009
Posted by editor in Agile Practices.add a comment
This is done by using your capacity. Lets use an example to illustrate this.
Say you are a member of a scrum team where there are 8 members , and you are following a two week Sprint.
So initial estimate of every team members capacity is 80 hours i.e. two weeks.
Some of the best scrum teams in the world work at 70 – 75 percent capacity. What that means is in the eighty hours they are at work, they would have to attend to company emails, go to meetings that are required at a company level, take lunch breaks, go on sales call etc. If you have another project then instead of 70 percent you only account yourself at 60 percent capacity. When many teams start with Scrum, we recommend them to start at 50 percent capacity. The other 50 percent accounts for day to day activities in your company.
Say your team is doing 50 percent capacity. That means each person in a two week sprint is only accounted for 40 hours. Out of which if you have a vacation day 8 hours, you take off 4 hours (The rest 4 hours you can account to the fifty percent)
Take a hypothetical example for a two week Sprint of a team at 50 percent capacity ( as this is a fairly new team to Scrum)
This team is made of Charles, Mike, Annie, Bob and Ray . Plus a scrum master. We don’t count the Scrum master’s hours in Scrum, unless they are pulling tasks off the task board .
Mike is there for both the weeks = 40
Charles has one day he is not there = 36
Annie is a part timer and she only works three days a week. So her capacity is 24 hours
Bob = 40
Ray = 40
Team Actual Capacity = 40 + 36 + 24 + 40 + 40 = 180 hours.
If the team worked all the two weeks at 100 percent capacity the would have a capacity of 8 hours a day * 10 days in a sprint * 5 team members = 450 hours.
See the difference of what is used in Scrum and the theoretical 450 that now one can work. That is what provides the cushion and allows for the team to provide a sustainable pace in every Sprint.
