How do I use "Completed story points in prior sprints" and "actual work"?

[Nicolas Urpi]

Those Items are clair their utility but I need some Reports of them, For Example, It would be good to know The actual Work Vs the estimated story points, to analyse how well the team is stimating.

The completed story points in prior Sprints would be great if Every time I specify for one story one much work was done in prior Sprint, that amount of work is summed to the velocity chart of that prevoius sprint and reduce for the actual one, to show a more realistic Chart! Nowadays, if I have Carry over I split my story in Two (Part 1 and Part 2) and then I split the story points as it shows the real work of each sprint.

Could somebody help me with this 2 important Items and how to use them!

Thanks in advance!

[Mark Segall]

Hi @Nicolas Urpi and welcome to the community!

I would recommend revisiting how story estimation is happening within the team.  By definition, stories are intended to be small efforts that can be started and completed within the sprint.  To get there it must go through a rigorous decomposition process as part of refinement and planning.  Therefore, they should not be in a state where one has to calculate a completion percentage at the end of the sprint.

Jira is designed for this best practices dynamic where a sprint is simply a block of time.  You estimate what can get done in that block of time and provides a committed vs actual report at the end.

[Nicolas Urpi]

Thanks for your Answer @Mark Segall .

Well, I understand your point and i share it. But the situation for me is that we are applying Scrumban. 

We use Sprint as a measure of time that help us tracking work and deployment but we have a dynamic backlog and team that takes new cases even at the middle of the sprint. This make us "split" cases that are work in two sprints. For that reason I would like to use "The completed story points in prior Sprints" for better assignment of the work/effort done each Sprint. 

If you know more about this Item and want to share with me, I'll be pleased.

[Mark Segall]

I totally get the realities of resource constraints.  However, mixing and matching frameworks is painful.  I recommend one of the following:

1. Go all in on Scrum
   1. Path 1 (plan for unplanned work) - Deduct a percentage of team velocity in sprint planning for unplanned events (e.g. velocity is 100, but we're only going to plan for 75). Then you have freedom to pull in unplanned work as the sprint progresses.  
   2. Path 2 (ruthlessly prioritize) - Set the expectation that items at the bottom of the scrum backlog are fair game for removal when unplanned work comes in and even pressure managers for whether the unplanned work is more important than what was already planned.
2. Go all in on Kanban
   1. Change your reporting metrics to be based more transactional (created vs resolved) over time instead of velocity

[Nicolas Urpi]

Great Help!

Thanks @Mark Segall