Dealing with some questions that I keep finding conflicting answers on
Hi everyone.
I have been a scrum master for a few years, and while we have been doing ok, I feel like i'm not improving enough and neither are our teams. To remedy this I have set aside some time to actual improve my own knowledge and try and remove some issues that have been bothering me and our teams for a while now. I hope this community can give me some good insights on how to improve. Sorry for the long post, I hope it's not problem.
My questions:
1. How do you deal with stories that are not completed?
We have an estimate/forecast. However not all work was completed. I think we should drag this story to the next sprint and keep the initial forecast. Meaning 0 of the work was completed in the current sprint because we simple have not completed it. I do not like to re-estimate it. If I do that the following situation occurs.
Say we have a story with 13 points, almost everything was done except for some unit tests that have to be completed. It's not finished so I drag it to the next sprint. In the next sprint, the team has 18 points available. The remaining work might very well be just 1 point. However I do not want to change the forecast so I keep the 13 points. In theory this would lead to the team only able to add 1 5 point story and their sprint would be full. But we all know that team can do a lot more. Are there any specifics or thoughts on how to deal with this?
2. How do you deal with stories being added during a sprint?
Our team completed all their work, but the sprint is not yet over. We like to add new stories to the board. This is very good, but how do you process this? Should we make forecasts for this work when we add it to the board? Do not forecast them? These numbers are not shown in our velocity because they were added at a later time. However I would like to track this somehow (using devops) because if this happens a lot, the team clearly has too high estimates and we should work on giving more realistic estimates.
Also, when we add a story but we did not finish it, what happens next sprint? Is it simple not finished, do you make a new forecast based on the work that is still open for that sprint? This stuff gets confusing in my head. I'm trying to find a good way to keep all the numbers clean so we can actually use them for a good presentation of our velocity.
3. Track time spend on stories?
Do you actually track somehow what time/points got spend on a story? I don't really do this. Sometimes we observe that a story takes way longer than expected and we talk about what we missed and we could do to prevent this in the future. But we don't actually track what stories take longer and take a lot less time. I feel we need to look at the work completed in the entire sprint and if that was also about the same as we forecasted. But as development is a complex field, sometimes some stories take longer and others take less than forecasted and i'm not sure we should even want to do that? Your thoughts?
4. How to deal with recurring stories?
We have a number of stories that do not get estimated with normal story points. These are stories that are time boxed.
To give you an example:
- Every developer needs to spend around 1 day per sprint on bug fixing/testen.
- Every sprint, we also release updates for our product. We divided all the tasks of any release over all teams. Each gets their own set of tasks related to the release.
We substract time spend on these time boxed "stories" from the actual number of points we can use to forecast.
Is this the correct way of handling it? Should we also give story points to these stories or just leave them blank knowing we time box it and remove that time from our time spend working on actual stories of the sprint.
5. How to deal with stories that have multiple teams working on them.
As I described in my previous question, our release process has a checklist with a bunch of tasks that have to be handled. We divide these tasks across teams as no team wants to do all these tasks, every single sprint. We thought this was the most fair solution. However this leads to some issues that we handle right now, but i'm not sure it's the right way.
We need a good view on tasks that are already handled and still have to be done. So we currently have a story with all these tasks and we place them on the board of 1 team!! This means, that others teams will have to check the board of another team to see what tasks they have to do. This feels wrong, but everybody also wants an overview of what is closed and what is still open. one team might be very busy and another team might like to help them our by taking over some of their tasks. Would it be better to give each team their own story with a set of tasks? How do I deal with seeing what is already done without having to check 5 different boards? I guess I can make queries but I don't feel queries really give you good representation of the current state (I should add that we use devops, as this might be an issue related to the tools we are using). I am afraid that if we split them up into stories for each team, that teams will not look at the total work for the release (and I already feel that the response from you might be, you should not have stories split up over multiple teams). But this is unavoidable unless we reorganize our teams to include the expertise of our SaaS team). Which is a small team (smaller than the amount of teams we have), and they work solely on improving our saas environment and they need each others feedback on a daily basis, so splitting them up would lead to a huge decrease in productivity from that team (and as we are currently moving all our products towards the cloud, this is not really an option sadly, though it might be in the future).
I'm just thinking aloud here, so feel free to ignore my personal rambling in between. I would love to hear you feedback/experiences.
I'm sorry for the long post, I hope I can post all these questions at once.
Thanks,
Guido
1. How do you deal with stories that are not completed?
The Product Backlog should tell the truth at all times about the work that is believed to remain. Work that is incomplete is not Done, and if it is worth completing, it must be retained on the Product Backlog and re-estimated. The Product Owner may or may not order it for possible planning in the next Sprint.
2. How do you deal with stories being added during a sprint?
Make sure they are being pulled rather than pushed and that the Sprint Goal is not being compromised. This new work does not necessarily represent a commitment, so be clear about whether or not it does.
3. Track time spend on stories?
If the Developers are applying good focus and limiting their work in progress effectively, would this need explicit tracking at all?
4. How to deal with recurring stories?
Are these really negotiable scope, or are they criteria for assuring a Done increment?
5. How to deal with stories that have multiple teams working on them.
They're jointly responsible for making sure they have an integrated increment, but you'd wonder why each team lacks the skills or competencies to complete a Product Backlog item under its own steam. Cross-team dependencies introduce complexities which then have to be managed.
How do you deal with stories that are not completed?
The Scrum Guide has one possible answer to this. Product Backlog Items that do not meet the Definition of Done cannot be released, cannot be presented at the Sprint Review, and are returned to the Product Backlog where they are reordered with everything else on the Product Backlog for future Sprints.
In theory, this is probably a good idea. In practice, it adds another dimension for the Product Owner to consider, especially for work that was started but not finished. Holding onto unfinished work and setting it aside to resume later often leads to problems with integrating the work. As other work becomes done, it could conflict or drive changes to the undone work when it's picked up later. This can increase the risk of integrating the work.
Whether or not to reestimate the work depends on the team. I'm generally not a fan of estimating to begin with, if the team is estimating, it can lead to situations where planning needs to account for the state of unfinished work and reestimation may make sense. If the team is struggling to plan with unfinished work, then it would make sense to dedicate some time in the retrospective to figure out (1) why there's unfinished work in the first place and (2) how the team should handle it when it does happen.
How do you deal with stories being added during a sprint?
Very carefully.
Adding new work from the Product Backlog is one of the last choices that I'd make if the team not only met the Sprint Goal but completed all of the Product Backlog Items selected for the Sprint. I think that the time would be better spent paying down technical debt, doing some technical enablement (especially if it is something that can help the team strengthen their Definition of Done), learning new skills, increasing the cross-functionality of the team members, or even giving people some time off to rest and recharge. Taking on these other things can help prevent you from having unfinished work that gets deprioritized and not picked up in the next Sprint.
If you are using velocity for planning, are estimating the work, and complete the work that you bring in, you absolutely should be adding it to the board for visibility and transparency and including it in velocity calculations of what you completed in the Sprint to help figure out what to bring in for the next Sprint.
Track time spend on stories?
If you're using flow metrics, you'll need some measure of the time on stories. You'll need time points in order to calculate lead time and cycle time. Together, with throughput, these are great ways to forecast work.
If you estimate in ideal hours, tracking hands-on time doing the work can help the team to calibrate the estimates. Knowing the calendar time can also help the team figure out the ratio between calendar time and ideal time for planning purposes.
There are also organizational reasons to track time. If your organization is capitalizing expenses, you may need to track time to figure out what effort can be considered a capital expense and what expenses are operational expenses. There may be ways to estimate this, so you'll probably have to work with the organization's finance department to figure out how to best do this in a way that doesn't add too much burden to the team while enabling the organization to achieve their goals.
Even though there are reasons to track time, they aren't applicable to all teams. If you don't have to do it, don't. Your tools may also be able to help make it less of a manual process.
How to deal with recurring stories?
I can't think of a good reason to have "recurring stories", or more generally, recurring Product Backlog Items.
Looking specifically at your examples, there are better ways to handle these two examples.
Bugs should be put on the Product Backlog and ordered with everything else. Some organizations prioritize bugs over all new development. Others look at the impact of the bug and decide where it goes. However, treating it like any other Product Backlog Item is a good thing to do. If you refine and estimate new development, then refine and estimate bugs.
Release work is something that shouldn't go on the Product Backlog. The Product Backlog is "an emergent, ordered list of what is needed to improve the product". Strictly speaking, the steps to release or deploy your product is not needed to improve it. If a release is happening during the Sprint, consider the effort during Sprint Planning and account for this when determining an appropriate Sprint Goal and how many Product Backlog Items to pull into the Sprint.
How to deal with stories that have multiple teams working on them.
Again, don't.
For actual product changes, decompose them to a level where a single team can take the unit of work to done.
For other work like you describe, something better than a Product Backlog Item would be better. Even keeping them off the Sprint Backlog would be good. Accounting for this effort in Sprint Planning would be best. Automating the process to reduce the manual steps and reduce the human effort would be even better. Work necessary to automate your release process is something that would be appropriate for the Product Backlog.
Thank you both for your replies:
How do you deal with stories that are not completed?
@Thomas, I understand your point of not estimating, but my experience is that more seasoned teams can do fine without it because they have a good grasp on what they can manage in a sprint. However the more inexperienced developers have a harder time doing this. Which is why I currently do want to keep track of estimations.
I do agree with your next point though about leading to more issues for not finishing the story. Some stories are split stories and depend on each other. We are working on a very large and complex product. It is not always possible to split up a story that far to get business value without completing multiple stories in order to finish it.
One thing I did read and think helps me is the fact that these estimations aren't about the value of the work being done, but the business value it provides. If you keep that in mind, re-estimation seems like the way to go, even if that means that team will see story points "disappear". I just wonder what impact this will ultimately have on getting a good velocity indicator.
How do you deal with stories being added during a sprint?
The stories we add are sometimes, but certainly not limited, technical debt. But technical debt are stories all the same so I don't really see a difference between a normal story or technical debt. Am I missing something here?
But if I understand you correctly, you are saying that when a story gets added, there should be an estimation, and also it should be included in the velocity numbers?
Track time spend on stories?
Hmm yeah I think I have ways of doing that, but it would mean converting story points into actual time and compare that to our work tracker. But I think I might forego this as I don't feel I want to harass the teams with this unless we really notice discrepancies.
How to deal with recurring stories?
In case of the release story, I complete agree with your argument. Which is basically what we already do. We reserve time for this in our capacity and we do not estimate it. Oh and I added a backlog with impediments focused on our release process to automate what we can to remove all these tasks, these will be fixed in the future as teams will fix these stories.
In case of bugs, I understand your point but I don't fully agree. I will explain why we do this differently but i'm open to suggestions. The issue is, we work with a very large code base in a complex product used by many large organizations. In between every major release, we can count on around 50 to a 100 bugs that are worthy of fixing (and a lot more reported, but not every bug is worthy of fixing). If our PO has to go through that list (from which half is technical by nature) and order them all, he would be doing this all the time and he does not have all the knowledge to make a good decision. What we do now is the following. 2 leads, a PO together with the service desk determine the impact it has on our customers and what prio it should have once a week in a session. They get organized into our bug tracking system in that order. Each developer spends time every sprint to fix one or more bugs (with the rule, the highest prio first). We want to prevent having to spend a lot of times on bug fixing before every major release and we want to fix the most immediate problems every minor release. If we don't timebox this, we would have to estimate every bug and that would be a colossal waste of time imho.
With smaller codebases, this would be a fine method I think. But I don't see it working properly with a large complex code base like ours. But again, I might be blinded to see other options as this is the way we have always operated, so feel free to tell me i'm wrong:-)
@Ian: Are these really negotiable scope, or are they criteria for assuring a Done increment?
As for the bugs, they fall into the first category. When looking at our release process, my guess is it falls in the second category.
How to deal with stories that have multiple teams working on them.
For actual product changes we do this already. It's not that 2 teams are working on the same story. However, sometimes teams do have stories that are related to stories being made in other teams. If we decide to rewrite the entire functionality of a certain module in our software because it's old and needs to updated to current day standards, this is not something we can do with 1 team. These kind of stories have a huge development cost and if we were to plan them with just 1 team, it would take a very long time. If we do this epic with a bunch of teams together, it will take a fraction of that time and it will actually get finished. However this epic will of course but split up into a bunch of stories that are divided over the teams. So I think we are good in this regard.
As for the release story I was discussing, I think you are correct in this regard. But I guess this is no different than any other epic/feature containing work that is being divided over multiple teams. I would have to break them down into stories per team. I'm just trying to find a good way to show the progress of all the work to all teams, while teams have separate tasks within that story. I currently do this by adding a story with all tasks to the board of 1 team, and add tags with specific tasks for each team to execute.
I can rotate this story as well I guess for a minor release through all the teams. But a major release has many more checks and tests to be executed. We automate what we can, but this is a long process and will take years before everything is automated. So I can't do it for a major release just yet, we will need multiple teams on this or this process will take way to long.
My question remains. What would be best, split these tasks up into stories for each team or keep doing it the way I am doing it now. I feel the teams will not have a good overview on what the current state is of all work if I split up that work into multiple stories. Do you have any suggestion on how to improve on keeping a good overview but still having specific tasks per team?
Thank you both for your replies!
Kind regards,
Guido