Yesterday in a talk at Google someone tweeted that Jeff Sutherland said “a team that concentrates on finishing ONE story before moving to the next will be twice as productive as other teams.” I thought that was rather enlightening since his expertise is in the area of hyper-productive agile teams.

I faced the very same issue, when I introduced agile the very first time to a team. But instead of having a burndown chart, we used a more Kanban like story wall as our main information radiator. So instead of seeing a “cliff”, we saw a big cluster of stories gathering in the “testing” column of our wall. And, of course, we had all the issues you mention in your post.

For us, making the developers aware of their responsibility to drive a story to done did the trick. They had to make sure they get a sign off by QA and finally the PO. Before we changed to that model, they had a “commit and forget” mentality: “Someone will be there to tell me if there is a problem with my stuff…”

The goal of teams should be to have the ability to have a story accepted every day (they won’t always use that ability, but they should have it). If this means the PO says automation is ok, or has a proxy PO or is simply more available doesn’t really matter to ME. It should matter to the team and the PO though. Get a way to say yes we can accept something every day and this problem (and many others) will go away.