Hopefully, with each of the 10,000 failures, Thomas (and most of us, with any luck!) learned why the attempt did not work. So, let me see if I can explain the things that I have seen not work, and then more specifically, explain *why* it did not work.
Immediately after our team's stand-up yesterday, we were being told about changes that were coming, set down to us from our "Release Plan Steering Committee" (formerly the Sprint Governing Board). We were told that we were going to try a technique wrt our user story cards that we had not tried before. Some people wondered why we don't handle these things the way(s) that we have all read about, involving user story cards, and breaking the highest priority ones down into tasks in the planning meeting to determine what we thought we could reasonably get done in a sprint.
What I found was the veteran team members started explaining all of the reasons that doing things that way had not worked for us. I started thinking of our original scrum master, and how passionate he had been ... and of Ken Schwaber saying that the average burnout is 18 months. Well, we are on scrum master number 2, and he is trying the same things that this team has already tried, repeatedly ..... So, let me start with the obvious.
Why not having a single, prioritized, and clearly defined product backlog does not work
Here is how this process has (not) worked for us.
When we started trying agile, we had "stuff" that we needed to build. We didn't have user stories, but we did have cards. We tried to go through this process of going into the planning meeting with cards, breaking them down into tasks to complete them and estimating how much we could do. But here was the problem: The team didn't understand enough about the desired functionality to break it down into tasks. As a result, we would spend the better part of a whole day trying to answer the questions we had.
Simple to solve, you say? Just have the Product Owner there, and he/she can answer those questions, and hopefully after a time of two of LOTS of questions, he/she will learn to start thinking through those kind of questions *before* the planning meeting!
Ah, there it was .... that word: "just". Our team has banned that word, among others.
Problem 1 with that statement: To this day, there is not a clear "product owner". There are several, and they conflict with each other, and ALL of their stuff is the Toppermost Toppermost priority. So I will have to write a "Why not having a product owner doesn't work".
At some point, our upper management decided that a *whole day* in planning meetings was too much. So we started having a shorter planning meeting - 1/2 a day. Well, since the lack of defined backlog items problem had not gone away, this just made things worse. We went into even *less* detail in planning, and we were WAY off of our estimates.
Next, they brought in a consultant, a scrum "expert", if you will. He suggested that we stop breaking things down into tasks and that we start writing better user stories. He suggested that we try to break each user story down into some detail on the back of the card, asking the questions of the product owner(s) before the planning meeting. He suggested that in the planning meeting, we just estimate the whole user story.
Okay ..... well, we have been dong that. And, we have struggled with estimating a user story card in story points, and then assigning a number of days to that story card. As one of our team members has said repeatedly, "when you estimate in hours, you are off by hours. when you estimate in days, you are off by days" (I don't know how much I agree with that, but ... it's not a bad concept).
So, the dictate that the team got yesterday from the Steering Committee says that we will no longer put days estimates on story cards. We will only worry about user story points and try to pick off the top
Can you guess how well this will work? I can .. and I think the way to fix the problem, is to fix the problem. We need a single backlog, and it needs to be well-defined and prioritized.