Po finding the teams doing scrum very differently
Hi,
In my organization there is one product and 2 scrum teams work on the product. The PO for the product is one person. So both the scrum teams have the same PO.I am the scrum master of one of the teams.
My PO came and told me and the other scrum master(of the other team) that she found both the teams doing scrum very differently. It was strange since each team does implement and strike a pattern while adhering to all the rules of the scrum guide. The other SM and I have decided to sit in each other's Backlog refinement session to try to see what we're doing differently. This is what I have noted
1) The other team does a prep before the sprint Review. They don't exactly demo but walk through all the PBIs with the PO. My team kind of felt this was an overhead as there is no point doing it just before the sprint review as you would probably review the PBIs during the Sprint Review. Our team does it a little different. Throughout the sprint whenever we complete the PBI we demo it to the PO and see if that meets here DONE and mark the PBI DONE.The problem is the PO finds what the other team does very useful since it helps her to walk through the Sprint Review part easier. My my team is reluctant and I do agree with them. What would you do?
2)We use TFS in my company. My team does not try to forecast which sprint the PBI will fall under. Instead we have turned off that feature. The other team does. Dont get me wrong they dont try to see where it will fit except that they have that feature turned on so they do talk about the fact that will fall into the next sprint and stuff.
3)My team timeboxes PBIs very aggressively. Their team does not timebox at all. Again there is no right or wrong here. Our team has always followed the rule FIRST PASS -(2 mins for the first pass, then we discuss and then again size), SECOND PASS - (5 - 10 mins, wont happen on the same day of refinement session), THIRD PASS -(15 mins , again it wont happen on the same day as the first or second passes). This gives a way for anyone who were on vacation to have a chance to view the PBI and if there are questions PO can get them answered. For my team this works out. The other team discusses the PBI and if they have any questions they write it down and get back to it the next time. They dont timebox like us. But I feel our team tries to timebox very very aggressively, which i dont know if it is the best way.
4)There seemed to be a lot of interaction when the other team discuss the PBI. I kind of felt the timeboxing concept on my team prohibited my team to talk through the PBIs? I am not sure. But none of my team members have said that the timeboxing doesn't work. In fact they like it a lot.
5)The other SM cleans up the PBI ahead of time and lays the PBI in a way that is easily understood. I have left it to the PO to do it. I do understand thats not my job as SM at the same time my team does struggle to understand the PBIs.(Our PBIs were written before the new PO joined the team). The other team easily understands and is able to move through PBIs easily.
6)Our PO seemed more at ease with the other team than ours. This could also be related to timeboxing as when we reach that time we try to move on.
7)They use the statuses in TFS differently.
What is your opinion? Again I just feel each team WILL do it a little different. But to make everyone at ease I want to strike a balance.
Hi there, I am currently a scrum master for 2 teams, that is building 1 product, with 1 product owner. So hopefully I am understanding the issues you state and can help guide you to a resolution.
1) Ask the team if they are willing to try the other method for 1 or 2 sprints? You can then discuss how it is going in the retrospective and always decide as a team to go back to the regular way.
2) Are you being asked by any stakeholders about which sprint a story will fall into? If there is no issue with not using this function, then great - you are maximizing the amount of work not done.
3) Ask the team if they currently like the timebox method that you are using and if they would change anything about it. Try those changes for a sprint or 2. 1 sprint it is still new, 2nd sprint they understand what has changed and it can be more effective on the 2nd sprint.
4) Ask the team if they want more time to discuss PBIs? Have you or the team seen any issues on not fully understanding PBIs? Do they ever get built and the PO says 'that wasn't what I wanted'? If that doesn't happen, I would say this isn't an issue. But again, ask the team, they know best.
5) Sounds like the other Scrum Master is doing part of the Product Owner role. I would sit down with the other scrum master and have them coach the PO on how write/manage the PBI in a way that helps the team best, that way it can positively impact both teams. The scrum master should help coach the PO on how to manage the backlog, but shouldn't be doing it for them - it does not help the PO learn and become all they can be.
6)Have you asked the PO if they are more at ease? Have you asked them why? Have you asked the PO what you could change about yourself (in the role of scrum master) to make them more comfortable?
7) Does this have any impact on anything? is it clear to the PO which team uses what status? Does it affect the teams shared definition of done?
Each scrum team is run differently and something that will help you out a lot is for you to ask the team about these 'issues' more. Not every problem needs solving and not every problem you notice is a problem for the team - learn to let these go, if they aren't causing any problems.
What balance are you trying to find? For what purpose?
I am happy to talk in more detail about these topics or anything else!
Tim
Some of these contrasting behaviors are not mutually exclusive. For example, it is reasonable to review (or even revise) PBI's with the PO during a Sprint, and it is also reasonable to demo work to the PO before the sprint end.
Backlog refinement is an ongoing activity in Scrum rather than a discrete event. It is nonetheless still a good practice to timebox each session. I'd question the value of timeboxing each PBI though, and I suspect that a PO might find this overly constraining.
I suggest you identify the various risks that the different approaches try to address and evaluate them in those terms. The risks that each team has to deal with may not be the same, even with the same product, and so some variation is to be expected.