Forecasting for Stories with no Story Points

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.

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?

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?

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. 

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?

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.