In my project it happens often that a user story "falls" out of the sprint where the most development effort has been put in, due to the testing etc not being completely done. So the effort put into a story in sprint x actually shows up in the next sprint (y) due to the testing being completed then. due to this the sprint reports are off, and it confuses people and makes planning a bit messy with effort estimations. also commitment and completed story points become weird to interpret.
Team set up is:
3 Development squads with 4 devs each, who pick up the first tests,
2 dedicated Testers, who deal with more integration, regression and performance testing.
Alternatives ive considered so far:
1. Splitting up user stories, marking one done in the "old" sprint, one in the "new" sprint
2. Manually track the effort spent at the end/start of the sprints, and keep separate reports (Dont like this at all)
3. Dividing user stories in parts of "as a developer" and "as a tester" to ensure the proper division of effort
To note, we do not follow the perscribed idea of scrum teams that have no specific roles, we do have a distinction between dedicated developers and testers.
Happy to hear your thoughts/experiences!
I'm running into a similar issue. Unfortunately due to dependencies the user stories spill over to multiple sprints, this can lead to incorrect velocity as we move the story points from one sprint to another. Is there a way to introduce a new field (something like Remaining Story Points) that can allow us to still have the visibility of how many story points we used to have vs the story point for that sprint?
Hello @Dipshikha Goyal
Jira allows you to create a new custom fields - check with your jira administrator for the same.
The Story points are estimate numbers, they are only supporting factors to help your team provide a predictable delivery and size the work, have a discussion with the team and see if the dependencies can be cleared during your product grooming event or on the sprint planning day.
It is normal for a team to have story spillover for multiple sprint, because story points are estimates it cannot be perfect.!
the best call would be to not take a user story into the sprint if it cannot be done, if you still commit, then the problem is to solve the dependency first.
how would adding a new custom field named "remaining story points" help the team deliver better? I think by doing so, you are doing a good patch (coverup) for the spillover, it may not help.
Empiricism in scrum is all about previous experience.
Hello @Bouke Krediet welcome
I suggest below points:
1. Make your user stories as small as possible so that they are "DONE" in one sprint
(this is easy to tell but it takes efforts to get the perfect slicing, but it's fun to work it out with a team)
2. Dont do a dividing story for developer and tester. (this is like the head of a human has a one birthday and the legs have another)
A User Story is a user need, and it is an action which the user does,dividing it spoils it and does not provide valuable feedback.
(what if there is a defect/bug in the story (developed item) which is done will you get back and reopen it?
testing is a part of the development activity finish them with the story.
If there are incomplete item at the end of the sprint (overflows to the next sprint), ask your team to evaluate them again, this will help you realize the amount of work pending and sometime this can be combined into one single activity (a task or something) which will enable a closure for the incomplete items soon.
Hello Community! I hope you've been enjoying the 🍂Apptoberfestivities🍂 (I know I have!) The event is heating up next week with a series of virtual events that we're calling the 🍻🍂Partner App ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event