Scrum / Sprint Queries regarding carry over
Hi - probably asked a million times but I want to get a clear path for going forward.
I have just taken over managing the development team its a small team. We are running 2 week sprints however to date they have been all over the place.
I am just introducing story points and trying to get a clear view of capacity.
The issue we have at the minute is we have 3 items that were not fully tested in the last sprint so in my head I want to carry them over to current sprint but the developers are moaning because from a deployment point of view ie back end VS they are linked to the previous sprint and to move them means creating branches etc.
For me they were not complete so they should carry over.
What is the norm here? We have a testing environment / a uat environment and then a Staging environment before swapping to live.
On the same note I have started to use Features and create smaller PBIs for elements of the feature so I am assuming here we just use branches for the whole feature?
Thanks
Michael
Those items remain on the Product Backlog because they are not yet Done. They ought to be re-estimated accordingly, and may or may not then be planned into a future Sprint. "Carrying work over" will rob the Product Owner of that value-based decision.
I'd suggest that a self-managing team would not require a manager, nor would they require elaborate branching and merging strategies. When teams fail to collaborate effectively on the same increment, they'll often resort to branching and merging as a crutch. Servant leadership may be needed to help the team explore, understand, and query such things.
The Scrum Guide provides a little guidance on what to do with undone work when the Sprint timebox expires:
If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
Given the ordered nature of the Product Backlog, it may not necessarily be ordered at the top of the Product Backlog. If some work has already been done, that may be one of the many factors considered by the Product Owner when determining the placement of these items back in the Product Backlog.
However, the situation that you describe leaves me with a lot of questions, such as:
- Was the Sprint Goal accomplished, even though these 3 Product Backlog Items did not meet the team's Definition of Done?
- Why were these three items unable to meet the team's Definition of Done prior to the conclusion of the Sprint?
- What does it mean that a Product Backlog Item is "linked to the previous Sprint"?
- What does not getting a Product Backlog Item to a Done state have to do with branching? Even more generally, what does a Product Backlog Item or features have to do with branching?
- What does the team think about the workflow from the selection of the Product Backlog Item at Sprint Planning to Done?
- What does the team think about the use of story points (and I'd assume velocity) for helping to assess the amount of work that can be done?
- What happens at the Sprint Retrospectives? Has the team been identifying these problems and attempting to come up with ways to solve them?
Hi Michael,
From some of the things you've said, I suspect that your team / employer are not really using Scrum. This would be a far more significant problem than branching or trying to determine whether items should be carried over from one sprint to the next.
It might be that your are using something that is being called Scrum, and it is likely that people believe it is Scrum; but a lack of awareness is often the first impediment that individuals, teams and organizations need to overcome.
My first advice would be for you to read through the Scrum Guide (the latest update from November 2020 is just 14 pages, including front cover and contents page).
Then consider how much is different when compared with your current context.
- Are any of the accountabilities not being correctly fulfilled?
- Are any of the events missing, not involving the correct people, or not achieving the purpose as described in the Scrum Guide?
- Are any of the artifacts or their commitments missing? Are these being inspected and adapted at the right moments and by the right people, as described in the Scrum Guide?
As for your role as a manager, many traditional management practices are an impediment to being successful with Scrum; particularly on relation to having a self-managing team.
Nevertheless, most organizations rely on leaders playing a positive role in enabling Scrum Teams to be successful.
I suggest you study at least some of Scrum.org's material on Professional Agile Leadership; particularly:
Of course, it's likely that exploring this will lead to more questions, so feel free to search or ask on this community for anything you are curious about.
I would say, if your team achieved the sprint goal, you should not worry about carry-over tasks.
Meet the goal is the most important thing rather than caging your team into a box. If testing not being completed, then it should be transferred to the current sprint, except the priority has been changed.
scrum is a method of working to delivery value incrementally, most people only consider value in production, but what's the value really? value can be way of working, experience, even complete half of the task, it should be considered as a value, because the next half of the delivery for the whole project can be shorten.
Remember your team is to delivery value, not to delivery scrum