This company (“Company X”) was an embedded RTOS provider. They, initially contacted us because they wanted to become more Agile. They knew they had a flawed implementation of Scrum and the initial scope of work was around Scrum training.
We quickly identified several other issues, though. They had no effective definition of done anywhere. Technically, someone had written a document titled “Definition of Done” and stored it on some SharePoint drive but it had fallen into complete and utter disuse. Nobody ever looked at it and many of the newer hires weren’t even aware it existed.
One of the main things that made Company X’s leadership think they needed additional Scrum training was the fact that story carryover was a constant thorn in their sides. Perhaps not every story carried over but close enough to it that it was understood to be a persistent pattern and a major problem.
The product owners, product managers, and the engineering teams, however, all seemed to be highly-skilled and very professional. So we knew we had “good material” to work with.
Since it was what started the engagement, we made sure to address the client’s concerns about Scrum. We re-educated the staff and leadership about what Scrum actually is and is not. Then we took it a step further by helping them understand and implement a healthy requirements maturation flow.
We re-introduced the concept of a Definition of Done (DoD) and made sure they understood that every work item – every single work item – needs its own, purpose-built definition of done. We also introduced the concept of a Definition of Ready (DoR), which must be defined for each work item. Of course, we helped them create and evolve templates so they weren’t starting from scratch every time.
On top of this, we ensured that their teams were using analysis stories to drive readiness of each work item. This allowed them to do as much analysis as was required to ensure a work item was truly ready and was not limited to just defining the requirements. It extended to things like discovering feasibility and understand the effort that would be involved in implementation.
Because the DoR had to be fully defined and satisfied and the team had a mechanism to ensure adequate resources were invested in analysis for a work item before that work item could be started, every work item was driven to be completely ready before implementation started.
As a result, estimates improved dramatically. Sprint plans became much better. In addition, things like delays from frequently unforeseen external dependencies almost disappeared completely.
The net effect was that story carryover practically vanished. It went from being something that was simply assumed was going to happen to being so rare it occasioned comment.