he thought it was the framework

it wasn’t

I was chatting with an engineering manager recently about how his Teams were starting on a Product Backlog Item (PBI) and unable to complete it within a sprint. They’d start working on the PBI and realise they don’t know enough about what they’re meant to do, so spend the next few days working that out. By the time the Team understands what the PBI is about, the Sprint is over it rolls into the next Sprint with little to no development. My impression was that he thought this was a failing of Scrum (and more broadly agile) because of the lack of upfront planning and documentation. I have seen this so many times, I know that it can be fixed relatively easily and fix other problems along the way.

When I encounter Teams having problems with understanding their requirements well enough to be able to deliver a valuable increment each Sprint, I have a standard list that I work through. First of all, I start by looking at the Product Backlog. I sit with the Product Owner (PO) and ask them to talk me through their creation, ordering, and auditing processes. Sometimes this can highlight that no one is fulfilling the PO role, which obviously is the root of all other dysfunctions being exhibited. Fix this before you try to fix anything else. Don’t fall into the trap of acting as the PO; you’ll fail at everything else if you do.

Once the PO and their ownership of the Product Backlog are in order, we can review the refinement process. I often find this to be lacking and the most likely root of Teams failing to be able to deliver frequently. I encourage Teams to look at refinement as a daily task. In Scrum, we find the more traditional Project Manager role distributed across the entire Team, including the Developers. By having the Developers involved as early as possible in the creation of PBIs, we can reduce organisational exposure to risk by uncovering unknown unknowns early. Once the Team thinks they have a PBI in a state ready for Sprinting, it’s time for estimation.

I fall right between the estimates and no estimates camps. I teach Teams that estimation has two clear purposes, and after they’ve achieved those, to throw away the estimate. I don’t want to see the recording of an estimate anywhere because it serves no purpose beyond the conversations they generate in the moment. The two purposes are:

1.     Do we have a shared understanding of the size of this PBI? If different Developers (and it should only be Developers estimating, btw) have widely differing opinions about the complexity of the PBI, then the Team can tell this by the disparity of their estimations. This should generate conversations around the knowledge and understanding of the work everyone has. It may be that extra work is needed to understand aspects that weren’t understood, or it could just be a quick conversation with one Developer with a specific skill set that another Developer doesn’t have. The Team will work this out.

2.     Do we think this PBI can be completed within a Sprint? (For more mature Teams, can this be completed within x days >= 1?) There is no point in bringing a PBI into a Sprint that the Team doesn’t think can be completed within the container. If the PBI is too large, then the Team needs to refinement it some more and probably create many PBIs in place of it.

While going through all of these evaluations, be sure to watch for the quality of the communication within the Scrum Team and between the Scrum Team and their stakeholders. It shouldn’t be that only the PO talks to stakeholders; the Developers must have access, too. Part of why I follow the process that I do, is because along the way it touches on all sorts of other potential dysfunctions. By the time I’ve supported a Team in creating a solid Product Backlog and Sprint Backlog, we’ve encountered and worked through many behaviours that can disrupt successful development.

After talking this through with the engineering manager, I could see light bulbs going on as he realised all the dysfunctions that were present in the lead up to the Team starting to develop. He had ideas about how he could help enable the Teams he worked with to work differently and get out of their way.