I've seen way too many teams working with just a big list of stories (they call it a backlog - but it's not). Many of these organizations can find someone to play the role of the (proxy) Product Owner, and that unlucky bloke will do the best they can at prioritizing the list... but it's still not a Product Backlog.What is really amazing is when you hand that unlucky PO a list of SIZED stories and they can see the cost of those wee little things that seemed like a big deal because we've all been living with that crap since forever. But now with the addition of a story size, those little nuisances become a top priority. The team's value goes up in the eyes of the stakeholders and users because the apps are visibly being improved.
"But sizing all those stories will take forever and a day."
That is what my product owner said a few years ago at a client known for its storage products. And being great organizers of storage, they put those skills to the list management they did with stories. They had a list for the next year's Christmas sale, a list for the new closet system feature, a list of lists and none of them sized by the team. I suggested we could take one of the list (about 80 items) and size that in about one and a half hours... the PO had sat through many story sizing meetings with planning poker cards and the endless technical details that developers could talk about for hours.
I introduced the team to REAL RELATIVE SIZING - a game played on the longest conference room wall with a piece of paper for each story. We first played the game with a list of dogs to groom. Only after we understood relative sizes did we turn to our work stories. We lined the wall with the stories - about 60 pieces of paper made it on the wall. There was a stack for the UNKNOWNS. A story got tossed in that stack by the PO when it was judged easier to kick it aside rather than explain what was intended. There were more than a few stories of this nature, which was handled by the PO who sat and watched, while answering email, and answering the occasional question from a developer.
It was valuable for her to see the process of sizing all those stories so fast. It gave her a sense of understanding the resolution of precision in those estimates of story size. And she never questions the team when they resized a story as it got better understood during backlog grooming or planning. She was very happy to be able to put a realistic time frame on the cost of the Christmas sale. And as a result, cut the sale to a third of the previous year's effort. The marketing team had truely gotten carried away with all the bells and whistles they decorate the site with.
Comments