Today we will discuss further on estimating the PBIs.
During product development there are three most important questions which are asked at very beginning.
- Time: When will be the development completed?
- Scope: How many features will be delivered?
- Cost: What will be the cost?
How we estimate PBIs?
We estimate Product backlog items
(PBIs)/stories using relative sizes, not absolute sizes. There are two most
common units of estimation- Story points and Ideal days. In these, ‘Story
point’ has got more popularity.
Story points:
Story points are measured
considering complexity and physical size of the PBI. PBI may be ‘complex but
small’ OR ‘simple but large’ OR ‘simple and small’ OR ‘complex and large’.
Ultimately we need to know the efforts required to develop that PBI. This is
achieved by comparing stories and putting points on these.
For example, if we compare two
stories and find that the latter will take 4 times the efforts than the first,
then we estimate the points for second story as points provided to first story
multiplied by 4.
A good strategy is to
start with the smallest story and providing it point(s). The question is how to
provide story point(s) to this story? Let’s assume that the smallest story is
about to create a UI for Registration form and the next story which is about
integration of a shopping cart in the application, when compared the latter
takes 4 times the efforts which first story will take. If the first story is
marked with 2 story points the next story will have 8 points (2 * 4).Ideal days:
Estimation in ideal days is a
technique of estimating PBIs and it represents the number of effort-days or
man-days needed to complete a story. Ideal time should not be treated as
elapsed time/calendar days. Ideal days are total effort in days and can span
for many days as per the hours utilization per day.
What is velocity?
The amount of work completed in a
sprint is known as team’s velocity. After each sprint the size of completed
PBIs is added and that constitutes the velocity of the team. Partially
completed PBIs
are not included in the velocity
as they do not have any value for the product increment.
To know the number of sprints for
the release, size of the release is divided by the team’s average velocity. So
for example if the release has 500 points and the average velocity of a team is
50, then it will require 10 sprints for that release.
Planning Poker
Planning Poker is a technique for
sizing PBIs. Planning Poker was first described by James Grenning (Grenning
2002) and popularized by Mike Cohn (Cohn 2006).
The game begins…
The Product owner describes the
PBIs and the ScrumMaster closely monitors, guides and motivates the team to
participate in Poker planning.
Each development team member is
provided with a set of Planning Poker cards for this game.
The product owner selects a PBI
and reads the item to the team. Development team members discuss the item and
ask questions to the product owner if any clarity needed on that PBI. Each
member of development team selects a card representing his estimate without
disclosing it to other team mates.
Once each estimator has made a
private selection, all estimates are simultaneously shown to all estimators. If
everyone selects the same card then it becomes the PBI estimate. If the
estimates are not the same, the team members discuss and repeat the same until
consensus is reached.
In no case average of the estimates
is agreed as an estimate for any PBI.
This is how we estimate the tasks
and velocity. If more clarity is needed on any point, please let me know. I
will try to reply as soon as possible…
In addition to what Deepak has mentioned, I would like to mention very important Size-Value relationship.
ReplyDeleteConsider a case where Product has two Customer say X1 and X2. Both these clients are coming up with some requirement on same time say on T. Now, both the requirement from these clients may differ in size or may have same size. When I say size, consider as efforts required for the implementation.
Let’s take a case where we have same size for both requirements, say L – Large T Shirt Size. Now, there may be cases where some clients are more important compared to others. So consider that scenario here, say X1 is imp client compared to X2. In this case, even if the size for both requirements are same, value for X1 > value of X2. And that plays an important role in prioritization and that priority is decided by your Product Owner based on the combination of Size and Value.
Same applies where size of the requirement from X1 is smaller than that of X2. In that case as well, this formula remains true.
Any comments Deepak?
I agree with this Ankit. In my future posts we will see more scenarios which are considered by Product owner during the prioritization of PBIs. Prioritization of such PBIs also depends upon the status of sprint whether the sprint is about to finish or just started and such stories may be included in the sprint moving the other PBIs for next sprint. Does these requirements are customized requirements? or do these items are bugs?
DeleteYou have definitely initiated a very important topic and I am sure this will be very interesting discussion over this weekend. :-)
Does this mean that the scrum backlog PBIs should be estimated in points only?
ReplyDeleteNo, not exactly. We do estimate in story points initially when prioritizing PBIs of 'product backlog' but once we start arranging stories for sprint backlog, we need to break the stories in tasks and the tasks need to be estimated in man-hours.
ReplyDeleteHope this answers your question. Please let me know if you need more explanation.