Skip to main content

Forecasting for Stories with no Story Points

Last post 02:23 pm August 12, 2018 by Marco Glorie
6 replies
08:44 am August 2, 2018

With our current project, we are dealing with data changes that we don't give story points to since we don't really see it as a product increment.

But as the Scrum Master of the team, how should I help the product owner to prioritize these types of stories since we cannot use the team's velocity to forecast them?


02:38 pm August 2, 2018

we are dealing with data changes that we don't give story points to since we don't really see it as a product increment.

Why?

Don't these tasks need to do any work?

Story points are used to estimate the size and cost of work, rather than the size and value of the incremental output.


02:52 pm August 2, 2018

But as the Scrum Master of the team, how should I help the product owner to prioritize these types of stories

Why would the Product Owner care about them at all, if he or she won’t receive an associated increment of value?


06:41 am August 5, 2018

I'll assume this is software development. Who says a releasable increment is only the result of code changes? If modifying data results in a change to the customer's experience of the product, could that also be considered a released increment?  Wouldn't that, in essence be an opportunity to gain feedback from the customer?

If work is required, and perceived value to the customer is being delivered, and there is an opportunity to gain feedback, why should these Product Backlog Items be treated any differently?


11:19 am August 6, 2018

Has the development team considered including this work as part of other related product backlog item instead of an isolated low-value one and estimate accordingly?

Even in the case that this low-value work has no direct relation to anything else, there is no rule saying you cannot represent it as a product backlog item, estimate it and give it a go during the sprint planning where it can be traded off with the PO. Would that work be of some risk in futures sprints if not done? In which ways? Non-functional requirements, data migration, data restructuring and other work that might be 'transparent' to the end user usually is deemed to be no less important and it consumes sprint development time as well. 


09:11 am August 12, 2018

I've been thinking about this lately, and I have recently re-learned that story points should represent the required effort to finish a certain story.

We used to put story points on these stories, but what we have noticed is that, this bloats up our velocity. Creating a script to change a product name or description is not as complex as changing an application-specific configuration. Currently, we are using a fibonacci sequence for our story points. Should we just change that so non-functional requirements like data changes won't blow up the velocity?


02:23 pm August 12, 2018

Hi Clint,

Could be that I do not fully understand your context, but 3 things come into my mind.

We used to put story points on these stories, but what we have noticed is that, this bloats up our velocity. Creating a script to change a product name or description is not as complex as changing an application-specific configuration. Currently, we are using a fibonacci sequence for our story points. Should we just change that so non-functional requirements like data changes won't blow up the velocity?

1. A user story described something that brings value. To achieve this, application specific things would need adjustments, as well as scripts on a database for example. These would be tasks in this user story. And everything that is needed to deliver the product increment including this user story needs to estimated by the team and be included in the complexity. 

 2. Sometimes more platform or life cycle management topics need to be performed by the team. It is common that the development team brings these topics up themselves. These are user stories as well, complexity needs to be estimated, and the value needs to be determined. This would usually not be direct user business value, but the value here will be in 'risk reduction' (your application will get less and less maintainable if you do not implement these topics) for example. 

3. You could take a look at the concept of 'Cost of Delay' (part of WSJF model) to estimate the value side of user stories. Can be very helpful if the product owner needs to prioritize different type of userstories.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.