I came across Thomas Schrantz’s article titled, “Why SCRUM Backlogs Lead to Bad Product Decisions.” The content begs a contrast between amateur and professional software development. In it he makes some good points about the traps many organizations fall into in their pursuit of delivering valuable, impactful software with agility. Here they are as I read them:
- Committing to and refining work that’s a long way off is very likely wasteful
- Description of features and technical specifications are not as helpful as description of customer benefits and outcomes
- Product Backlogs can easily become unmanageable “everything” buckets without active refinement
- The Product Owner will likely need the help of people, tools or techniques that bring clarity to the vision expressed in the Product Backlog
Thankfully, the Scrum framework appears to agree heartily with Mr. Schrantz. Read the Scrum guide and see if you disagree.
Forecast vs. Commit
Software development is unpredictable. Commitments are predictions. When confronted with the unpredictability of product development, the professional Development Team moves away from predictions. Instead, they use observations to form realistic guesses that Scrum calls forecasts. These guesses are enhanced by data and probability. Done well, forecasting is a much more honest way to communicate intent and likelihood to bosses and clients. Ultimately, it helps professional teams build trust and thus help repair the mistrust that frequently marks these relationships.
Commitments may still exist, but they tend to sound different. For example, a team won’t say, “We’ll have ‘X’ feature by ‘Y’ date.” Rather, they’ll say, “Given what we know now, there is a 90% likelihood we’ll deliver ‘X’ feature between dates ‘Y’ and ‘Z.’ We’ll update this forecast in 2 weeks.” Some would say, “My client won’t accept that kind of forecast. They need us to commit to feature go-live dates in order for us to win contracts, RFP’s, etc.” I sympathize with you, but realize that your client is asking you to lie to them. Further, you are obligating yourself legally by signing the lie into contract.
For a project of any significant complexity, you cannot guarantee A) it will be done by a particular date and B) you will maintain a sustainable pace of development.
Here are some things that affect the sustainability of development pace:
- Work/life balance for Scrum Team
- Technical debt added to or taken out of produce
- Time set aside for innovation and continuous learning
In my experience, commitments tend to encourage:
- A lot of crazy work hours
- Poor, technical choices caused by lack of time and focus (and probably sleep)
- Refused requests for conferences, training, book clubs, team building, Fedex days etc.
Be professional and do the hard work of learning how to forecast accurately. Resist the urge to tie your hands with precise predictions.
Big Design Up Front vs Last Responsible Moment
Amateur teams spend too much time creating plans to implement work before they should. In many organizations, this takes the form detailed plans handed down from architecture teams. While this may seem appropriate, it often leads to waste when circumstances change. Professional teams work hard to be cross-functional. They possess the ability to create emerging architecture as needed just in time.
Amateur teams may also spend too much time refining too far down into a large Product Backlog. When things change and Product Backlog items get move lower or even removed, that analysis or design work is wasted. Professional teams work hard to refine just enough Product Backlog, just in time. They resist the urge to create implementation plans beyond what is needed to forecast the next couple or 3 sprints. In depth analysis and design is saved for Sprint Planning. It is true that a little crystal ball reading might be needed at times, yet such efforts likely contain waste and should be viewed with suspicion.
Outcomes vs Output
Measuring the outcome of our work is much harder than measuring our output. Our output is lines of code, pages of documentation written, mock-ups created, designs constructed, research concluded, etc. Outcomes are things like higher revenue, reduced support tickets, fewer angry calls from clients, increased API usage, etc. Amateur Scrum Teams maximize production and professional teams maximize the valuable impact of their work.
Scrum emphasizes outcomes by insisting that working software be produced every Sprint. Valuable impact is the focus of a well-crafted Sprint goal. A preoccupation with measuring then maximizing value of work is the job of a professional Product Owner.
Context vs Catalogue
Amateurs Scrum Teams think a big, flat list of requirements alone may be sufficient for a Scrum Team to produce its most valuable product. Professional Scrum teams eliminate waste by choosing to work on the right work first. Knowing the right work requires context.
Thankfully, Scrum does not require that the Product Backlog be a large, flat list of requirements. Further, it doesn’t require that a Product Backlog be an “everything bucket.” According to the Scrum Guide, the Product Backlog is:
…an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.
The phrase “…everything that might be needed…” gives great discretion to the Product Owner. It does not bind (s)he to write down every idea for the product (s)he comes across. Although many Product Owners do use the Product Backlog this way, many find it more useful to keep the backlog well refined by routinely trimming out the cruft. Additionally, products of a certain complexity or scale tend to have very large backlogs which beg the help of other people and sophisticated tools. User story maps, road maps, digital backlogs, buyer/marketing personas, and people that help the Product Owner refine the Product Backlog are all techniques used by Scrum Teams that value rich context in the Product Backlog.
Amateur vs Professional
Mr. Schrantz has warned us against premature commitments, technical myopia, apathetic refinement, and an unsupported/weak Product Owner. They are indeed wasteful, wrong-headed, lazy, uncaring, and unfortunately quite common. Professional software development using Scrum looks much different and is much rarer.
Professional Development Teams value rigorous forecasting rather than rigorous commitments. Professional Scrum teams value a contextual Product Backlog rather than a catalogued Product Backlog. Professional Development Teams value measuring the outcome of their work rather than their output.