Story points related doubts

*CORRECTION : Each developer works 6 hours a day and 60 hours a sprint 

I'm going answer #2 first.

I have often used your definition to explain an Epic.  But I use is as simple illustration.  In my honest opinion, an Epic is something that defines an opportunity to solve a problem that is too large to show progress on in a single sprint. I encourage my teams to refine any story (not just Epics) into something that can show progress to the stakeholders in less than a sprint.  That gives them some "wiggle room" in case they discover something mid-sprint. 

Now #1.  

If you follow your own rules, this is a 12 minute/day x 10 days activity. That makes it 120 minutes or a 2. I'll assume that restarting takes the same as starting and recommend that you do some kind of "average expected script failures" to arrive at some time to add to the 120 minutes and adjust your estimate accordingly. 

But let me get on my soapbox for a minute.

I really have a difficult time when people estimate based on hours and call it agile.  I realize that many companies using agile are consulting/offshoring companies that bill by the hour so they have to show the figure.  But agile isn't about managing hours.  It is about managing value. 

Let me pose this scenario to you.  Before you start working on a story, you have estimated it to be 8 hours of work.  Your team only works 6 hours a day so that story will be more than a days effort.  So the developer starts working on it at 10:00 AM.  About 3:00 PM they uncover some unknown, unforeseen issue that is going to increase their work by an estimated 7 hours.  That 8 hour task has now become a 13 hour task. But everyone on the team, including the developer that uncovered this information,  has already been fully booked at 60 hours.  So now, this person is faced with 67 hours of work. And that assumes that nothing else is discovered.  Now, assume that 2 other developers have ran into the same situation.  Very soon your carefully planned 60 hours of work per developer has been totally destroyed and you are into "overtime" which starts to impact your sustainable pace and velocity.

It would be more appropriate to come up with a model that you can use to bill your clients based on the value that will be delivering.  I will admit that I don't have an answer for that. I've been trying to come with one but can't help you yet.  I would not be surprised if someone else on this forum might have such a model that could be shared.  Any up for that challenge?

Off my soapbox now.

1.We need to assign hours for below activity. How should we deal with it ?

...

2. Epic user story is any user story which is so huge that it cannot be completed in a sprint and needs to be further refined (Broken down).

...

Can you explain why your team finds difficulties in estimating such work, using its current time-based scheme?

I see a lot of back and forth in my reading about the evil of using points compared to hours, hours compared to points, story counts as opposed to either of the aforementioned. 

The problem, at least as I see it, is that relying overmuch on points or hours or any other measurement, is that it becomes the outcome rather than the delivery of a working piece of software.

On the other hand, it's extremely hard to bill by value of the work product, unless the customer is willing to put a dollar value on it for you or asks you to, which runs the risk of sticker shock. 

I wonder if you couldn't do a similar comparative ranking process using a Fibbonacci sequence with the backlog to do a comparative estimation of value.

So you could say that each point of complexity is so many dollars and multiply that by the ranking of how valuable it its to the customer to get your MSRP of the feature, and then track hours to identify your costs to complete.  The value rating has to be agreed upon by you and the customer.  

As you do the process, you'll be able to identify the actual costs of providing items, which will allow you to adjust what you charge based on empirical evidence.



Caveat: This is more of a mental model than anything I've seen used in practice.  



 

@Daniel Thanks for your answers. Your #2 answer is very practical. Often our developers do face this issue and the result is unfinished work or stretching to complete the work, even though work allocation is done by assuming buffer. Unforeseen issues do crop up(Example: network down)

I am not very much sure how the client billing is done. After each sprint, we need to give report to management about story points completed /carry forwarded stories etc in that sprint. so I  it may be based on story points delivered.

If indeed billing is done based on story points, then can it be considered as billing based on Value ??

@Ian It's not actually. Somehow by looking at it first time I found it confusing.

@Larry Appreciate your suggestion.

If indeed billing is done based on story points, then can it be considered as billing based on Value

Story Points are a measure of either complexity or effort (depending on your usage). I've never seen them being used for  measuring value.

I am not very much sure how the client billing is done. After each sprint, we need to give report to management about story points completed /carry forwarded stories etc in that sprint. so I  it may be based on story points delivered.

How does the Product Owner work with the team to maximize value? What explanation does he or she give regarding how it is determined, and whether or not it is worth continuing with further Sprints? It's unlikely that stakeholders will find value in story points.

@Julian,  Noted !

How does the Product Owner work with the team to maximize value? What explanation does he or she give regarding how it is determined, and whether or not it is worth continuing with further Sprints? It's unlikely that stakeholders will find value in story points.

@Ian , Product owner "almost" never interacts with the team. So, our client is basically major US client in entertainment industry having parks & resorts. The client has hired manager in US who is employee of some third party. She is very much active and present in scrum ceremonies. But, her focus is mainly on how much work is remaining , when it will be completed, how many open bugs, how many new bugs, managing timelines, giving explanation and giving status update to higher management from client side. So, basically, discussion about maximizing value and how the value is determined is nowhere in picture. But I would like to believe it's adding value because we are delivering features required by client (The software is for client itself) & client employees have started using it. BA gathers the requirements and we deliver the features. 

@vishal  with your method of using story points for hours, you can bill based on story points.  But because of the situation we discussed about unexpected information being found, you are actually losing money.  I still think that you need to find a way to bill based on value provided.  @Ian and @Larrry are trying to lead you the same way. I actually like @Larry's suggestion but as with him, have never seen it used.  Maybe you can blaze a trail, share the results with the rest of the world.  After all, agile is all about experimenting to find the right solution. :)

Based on your description of the Product Owner's interaction it sounds like that PO does not understand their role in Scrum.  They are instead being a Project Manager.  Maybe your company should invest in Product Owners who can work directly with the clients to help them understand how Scrum works, how value is provided and then help them understand how they are paying for value instead of hours. 

Your situation is not unique. There are a large number of companies doing what you do and they would all face this situation.  If you know of others in your area, it might be worth reaching out to some of them and discussing how they are handling this. They may not want to give away "trade secrets" but it doesn't hurt to try. And if nothing else, it shows that you are willing to be transparent and it may encourage them to be also.

I wonder if you couldn't do a similar comparative ranking process using a Fibbonacci sequence with the backlog to do a comparative estimation of value.

Yes you can, as in value poker. Another technique is to assign items on a product backlog notional amounts of money from a fixed pot (e.g. Monopoly money). Each Product Backlog item has a value attribute which ought to be forecast in some way.

So you could say that each point of complexity is so many dollars and multiply that by the ranking of how valuable it its to the customer to get your MSRP of the feature, and then track hours to identify your costs to complete.  The value rating has to be agreed upon by you and the customer.

This would seem to introduce an element of the price a customer is willing to bear. I don't think that would work out too well as it would increase the cost of innovation. Valuable items with a higher MSRP might just end up being pushed further down the backlog, for example. Stakeholders are looking to agile development precisely because they wish to secure an unfair advantage.

However, the Product Owner is accountable for what value is, and how it is determined. If a PO liked this sort of approach then they would be free to implement it.

However, the Product Owner is accountable for what value is, and how it is determined. If a PO liked this sort of approach then they would be free to implement it.

So, in this approach product owner will have last word on deciding value (and thus billing for client).

Most of you have worked in multiple Scrum projects. So, I just want to know, product owner is "always" from client organization or he/she can be from the organization to which the work(software development) is outsourced ?

Because, in former case, there is more probability that he won't be fair (to save bucks). We are telling our customer to choose what price you want to pay for a piece of work. Correct?  

I just want to know, product owner is "always" from client organization or he/she can be from the organization to which the work(software development) is outsourced ?

Scrum imposes no such constraint. A Product Owner can be affiliated with a client, the supplier, or might even be an independent third party.

Because, in former case, there is more probability that he won't be fair (to save bucks). We are telling our customer to choose what price you want to pay for a piece of work. Correct?

The value attribute of a Product Backlog item does not necessarily reflect the price a client wishes to pay. It might do, if the Product Owner wished, but this is unlikely as it would risk increasing the cost of innovation.

My advice is to consider the price a customer pays for an item separately from value. In general, innovation should be kept as frictionless as possible. Indeed, assuring this may be seen as part of a Product Owner's job.

There's nothing to stop a Scrum Team from also being stakeholders with equity in the product, but any gains thereof would be separate from development costs.

@Ian has nailed it.  I am going to give you an illustration on "value" vs "price" that might help. 

You have a problem in Production that will take 10 hours to fix but it is costing the company $2.5 Million every 3 days. 

You have a problem in Production that will take 10 hours to fix but it is costing the company $1.50 every 3 days.

Which one has the higher value given that both will have the same cost to fix?  No matter which organization the Product Owner is from, I would bet that the first one would be chosen to fix.

Yeah, this is extremely simplified but it is just an example for illustration purposes. If you ever encounter something this simple to evaluate, I would be buying Lottery tickets that same day.

Hope that helps. 

I have mostly worked on internal software, so my thoughts about this are jaded by that somewhat.



One of the issues we run into, much like healthcare, is that the end costs of decisions are hidden from the very people who need to make the decision. 

My thinking is that if they know that a certain item is going to cost more, they will either reduce the scope, deprecate the feature, or make decisions based on cost rather than the value of the Product Backlog item. 

There may need to be a note that certain things are at a fixed cost or must be at the top of the Backlog because they are the underpinnings of everything else, or that the value/cost equation doesn't happen until sprint review and planning for the next sprint, since the stakeholders will have more information at that point and can make better decisions.

There are other considerations as well, urgency being one of them, which may need to adjust things.  Injections after the sprint planning is another item that should have a cost, or at least the customer should be asked to choose between the injection and the work already planned.

Everyday, throughout the 2-week sprint, run a script in the morning (2 minutes), gather data at the end of the day (5 minutes) and put it into the spreadsheet (5 minutes). Whenever script fails during the day it needs to be restarted.

In my mind, for this automation is required and not every day work. To do this user stories and related tasks need to be created to archive this automation by development team. I would suggest billing the implementation and monthly service or just monthly service for some amount. If automation is only per one client, when he stops paying you can kill the service.

The value attribute of a Product Backlog item does not necessarily reflect the price a client wishes to pay. It might do, if the Product Owner wished, but this is unlikely as it would risk increasing the cost of innovation.

My advice is to consider the price a customer pays for an item separately from value.

@Ian, Okay.. So, if can you suggest the parameters to be considered for billing? 

My thinking is that if they know that a certain item is going to cost more, they will either reduce the scope, deprecate the feature, or make decisions based on cost rather than the value of the Product Backlog item.

This is how it should be..Isn't it ? You know the value, you know the price , Now you decide what & how much you want. Please correct me.

You have a problem in Production that will take 10 hours to fix but it is costing the company $2.5 Million every 3 days. 

You have a problem in Production that will take 10 hours to fix but it is costing the company $1.50 every 3 days.

Which one has the higher value given that both will have the same cost to fix?  No matter which organization the Product Owner is from, I would bet that the first one would be chosen to fix.

@Daniel, You mean to say, cost can't always be  proportional to value. So are you advocating "hours worked" as the basic parameter to be considered while billing? 

@Denis, Noted ! 

can you suggest the parameters to be considered for billing? 

What are the costs of actually running a team Sprint by Sprint? How close can you get to implementing that billing model?

So are you advocating "hours worked" as the basic parameter to be considered while billing? 

No I am advocating value delivered as the basic parameter.  But I also admit again that since I have never had to deal with this exact situation, I don't know how to do that.  I understand your predicament and I am extremely interested in this conversation because it is giving me a chance to learn.  

My premise for advocating value delivered is because that is how a scrum team that is completely internal to a company is "judged".  If the team is not delivering value their existence will be questioned.  But if a team is consistently delivering value, their existence is never questioned.  Nor is their process, pace, organization because they have self-organized into a unit of people that are worth the money the company pays them. 

My premise for advocating value delivered is because that is how a scrum team that is completely internal to a company is "judged".

Three things I suggest considering:

1. Perhaps value delivered is how a product or service ought to be judged, not the team working on it.
2. Companies do not always have a robust understanding of what constitutes delivered value in the first place. For example it may be seen as "executing projects faster and cheaper".
3. A significant constraint is the speed at which organizations learn. A team which can evidence good innovation accounting, Sprint by Sprint, may be worth continued investment.

+1 @Ian.  Or should I say +3?  

All good points.  Thanks for the perspective. 

No I am advocating value delivered as the basic parameter.  

Sorry..But it's a bit confusing now. In October 24th post, Ian mentioned -:

The value attribute of a Product Backlog item does not necessarily reflect the price a client wishes to pay. It might do, if the Product Owner wished, but this is unlikely as it would risk increasing the cost of innovation.

My advice is to consider the price a customer pays for an item separately from value. In general, innovation should be kept as frictionless as possible.

I interpreted above para as - : Do not try to relate value and price. But, going by recent posts, I think I have missed the point. 

Try to think of it in terms of minimizing the leap-of-faith (the amount paid up-front) before value is actually obtained. Remember that value only comes from the increment once it is released. That’s when value is empirically demonstrated.

An individual Product Backlog item has no value at all until it is released. The “value” attribute is a forecast which can help the Product Owner to order the backlog so delivered value will be maximized. Charging for an item on the basis of its value attribute would be milking the cow before it has eaten the grass.

The amount a client pays to get something will be a leap-of-faith until value is obtained from the product. The value earned will have to justify any investment (e.g. the price of milk must justify the cost of pasture) and to that extent value and price are indeed “related”. However, the leap-of-faith will be minimized in an agile, innovative environment. The barrier to entry, and the cost of innovation, will be deliberately kept as low as possible.

For example a client might fund development on a Sprint by Sprint basis (pay something, get something). The price paid each Sprint might cover the costs of development and no more, the supplier asking for a cut of future profits should value be demonstrated. Hence price and value can be effectively decoupled through the shared management of risk.

So, the ideal billing model in scrum should  be --> Fixed Cost (for Sprint) + Variable Cost (Depending on value).

Thanks Ian for the excellent explanation. Much clear now . 

But is this model tried & tested by any organization any of you have came across?

And secondly, supplier and customer cannot always reach to consensus on value. How to deal that situation. According to me, to avoid such conflicts, there should be agreement between two parties in which benefits of functionality should be divided into tactical (improve the day-to-day running of an organisation. Example: saving of paper ) and strategic(Example: functionality which allows customer to identify new trends in market)

But again, question remains, can all tactical or for that matter all strategic benefits can have same value? Obviously No. So, further bifurcation is required. Please correct.

But is this model tried & tested by any organization any of you have came across?

Any company with developers on the payroll who get a base salary regardless of outcome, and a bonus if things go well. The cost per sprint for the team will be known and funding will be a leap-of-faith until value is delivered. It doesn’t matter if the product is for internal use or for an external client. If the investment is justified then value will be obtained and the team will get a share.

The difficulty lies not in finding companies which implement this model, but in finding examples of those which do it well. Most organizations have a very poor understanding of what value is or how to account for it incrementally.

Any company with developers on the payroll who get a base salary regardless of outcome, and a bonus if things go well

Okay..so similar model. But my other question still remains unanswered.

supplier and customer cannot always reach to consensus on value. How to deal that situation. According to me, to avoid such conflicts, there should be agreement between two parties in which benefits of functionality should be divided into tactical (improve the day-to-day running of an organisation. Example: saving of paper ) and strategic(Example: functionality which allows customer to identify new trends in market)

But again, question remains, can all tactical or for that matter all strategic benefits can have same value? Obviously No. So, further bifurcation is required. Please correct.

And it will remain unanswered for nobody can offer you a panacea. A lot of valuable advice has been provided, try to work out the best path for you

And it will remain unanswered for nobody can offer you a panacea. A lot of valuable advice has been provided, try to work out the best path for you

Don't jump the gun..Don't reach to the conclusion that it will remain unanswered. If questions are not raised, half information is of no use. In any case you did provide no valuable inputs so I am anyways not seeking answer from you..So instead of just being rude and jumping in between the conversation take a chill pill.

Are you a Dan - Mad Sweeney persona?

First of all, you were the one mentioning "But my other question still remains unanswered." as if there is an obligation (moral or otherwise) for this community to provide an absolute answer to you, one that will satisfy your "requirements".

Then I advise you, in good faith, that your question will remain unanswered because there simply is no panacea and it is up to you to work out a solution, and the doctor in you advises me to take a chill pill. Well done, mate.

FYI, I did provide no input because there was nothing for me to be able to contribute. Other people have already given you some ideas/hints.

supplier and customer cannot always reach to consensus on value. How to deal that situation. According to me, to avoid such conflicts, there should be agreement between two parties in which benefits of functionality should be divided into tactical (improve the day-to-day running of an organisation. Example: saving of paper ) and strategic(Example: functionality which allows customer to identify new trends in market)

But again, question remains, can all tactical or for that matter all strategic benefits can have same value? Obviously No. So, further bifurcation is required. Please correct.

Well according to me there is no limit to bifurcation. But on high level there can be agreement between two parties. I would advise don't go deep in bifurcation and keep it at high level as it would lead to more confusion.

Thanks Prasad..couldn't reply earlier as I was out of town.

I found one great post by Jason Knight about measuring the business value of pbi . 

http://accentient.com/blog/measuring-the-business-value-of-a-pbi/