BI never gets done in a Sprint
Hi
I am on a new job as Scrum Product Owner for a scrum team in a product company. The project has been going on for six months and is expected to be completed in six more months.
My role is, among other things, to prioritize all BI (Backlog Items) in the backlog, which is found in TFS.
There are many problems when coming as a new Scrum PO in an already ongoing project. But the biggest problem is that when I look in the backlog in TFS I don't understand it!
Each BI (Backlog Item) has 4 tasks: 1) ”Requirements” 2) ”Implement” 3) ”Create Test Case” 4) ”Run Test Case”. It is hard to read in the board and understand what they actually is doing.
But what is worce is that when a BI is selected in a 2 week Sprint, it is never finished in that sprint. Because the last two tasks in the BI "create test case" and "run test case" can never be carried out. Task 1 and 2 are set to done and the BI is selected in to the next sprint. So it feels that the team never ”success” with a Sprint becase an BI never can be done in one sprint.
What do you think the problem is here? And how would you have solved it?
best regards
First thing I would do is talk to the Scrum Master. Since that individual is not new, they should be able to give you some insights into how/why this happens and why the team feels that the way they are doing things works for delivering value consistently. If the old PO is still available, have the same conversations with them.
As for not being able to understand the BIs, it sounds to me that they are poorly written. This could be a contributing factor to the problem of the team not being able to finish the work. In progress discoveries often happen and will frequently have impact of increasing complexity which can lead to needing more time to do the work. If these stories have been deemed ready to be pulled into a sprint by the Development Team, have them explain them to you. Get them together for a Refinement session and ask one individual to explain a story to you. Chances are you will find that after that description, others in the room will speak up with differing interpretations. The discussion that ensues will help the entire team come together on an understanding. Repeat the process for another story having a different person start the description conversation. Then based on that information, you can start to order the backlog appropriately.
One thing I want to caution you on is the use of "prioritizing the backlog". The Scrum Guides states that the backlog should be ordered in a manner that allows the Development Team to provide the most value. Let me pose a scenario. You have 2 stories in the backlog. One of those stories will help the sales organization close a $1,000,000 deal but it will take the team an entire sprint to finish. The second story will provide a function that 3/4 of your user base has been requesting and will take the team 3 days to complete. One could argue that the $1,000,000 deal is a higher priority than the new feature. But delivering functionality to 3/4 of your user base vs closing a deal with 1 company might be higher value delivery. So which would you put at the top of your backlog if the purpose is to ensure the Development Team is providing the most value?
What do you think the problem is here? And how would you have solved it?
Is the “backlog” you refer to a Product Backlog, or a Sprint Backlog? Based on what you say, it would appear to be both and neither, and these are the consequences.
.find_in_page{background-color:#ffff00 !important;padding:0px;margin:0px;overflow:visible !important;}.findysel{background-color:#ff9632 !important;padding:0px;margin:0px;overflow:visible !important;}
Get them together for a Refinement session and ask one individual to explain a story to you.
This is a "technique" I find utmost helpful to check if the PBI is interpreted by the team members the same way the PO intended. I once had a team member who used the whiteboard to draw out his interpretation of the BI and it was waaaay off what the PO meant, but also what other team members understood. So there were multiple interpretations. This became quite a big part of the retrospective to figure out what could be done to make this more clear.
Maybe try to write to the PBI's according to INVEST, if you're not already doing that.
In addition to what's been mentioned above, may we know if the team estimates the work before starting it? If they do, what size are those items?
It could very well be that those BIs are too large to complete in a sprint (how many members in the team by the way?). It could also be that the BIs are actually a collection of stories, hence the need to break it down further into smaller pieces that can be approached (picked up) individually. Furthermore, it could also be that the team isn't really confident they can complete the work, but they are reluctatnt to share their concerns with you or their managers. And so forth.
How about the sprint goal? Do you use sprint goals?
How about retrospectives? You should discuss, go down to the root(s) of the problem(s)
You say you are using Scrum, therefore I'd suggest you review the Scrum Guide; focus on the values and the pillars. Take all the time you need, today or at the earliest, to chat with the team members and have a full (or as full as it can get) discovery.