Precision in Language

One of the more important things I learned in graduate school that applies to my work in the software industry is precision. When I talk about precision, I mean being very clear about what you are claiming (or not claiming).

Earlier today, I read this question at the Scrum Development group which illustrates why it is important to be precise in your language:

“Can the product owner post tasks that are poorly defined and require the team to take the tasks?”

My first response was to answer the question, but then it really was not clear if the poster was asking if it was allowable for the Product Owner to put items into the Sprint Backlog or the Product Backlog. Where the imprecision started was on the terms “task” and “require”.

In Scrum, tasks are identified by the Team in the Sprint Backlog. In that context, Scrum is very clear; the Product Owner cannot post tasks into the Sprint Backlog and “require” the Team to do anything. The Sprint Backlog is owned completely by the Team (because they are self-managing) and they have the final say of what goes in and what goes out. The Product Owner might suggest tasks and may even have a list of things they think the Team might need to do, but in the end, it is the Team’s responsibility to fill the Sprint Backlog with tasks that complete the Product Owner’s goals for that Sprint.

What confused me next were the words “tasks that are poorly defined”. Could the poster be referring to the Product Backlog? In that context, the Product Owner does have the authority to have items “poorly defined” (it is their Backlog, so it can be in any form they want) and can ask the Team to accept these loosely defined items into the Sprint. However, like most everything I have studied about Agile software development, there is a balance here. In exchange for allowing the Product Owner to have things loosely defined, the Team must accept the responsibility to ask enough questions to understand the exit criteria, the requirements and gather enough information to make a commitment. If the Product Owner cannot provide enough detail at Sprint Planning to satisfy these three conditions, then the Team can turn back the request.

“Can the product owner post tasks that are poorly defined into the Sprint Backlog and require the team to take the tasks?”

If the original poster had written something more precise (with the correct application of Scrum vocabulary) we could have saved so much time in learning about the problem.

“Can the product owner post tasks that are poorly defined into the Product Backlog and require the team to take these as tasks into the Sprint Backlog?“

The extra precision describe different problems faced by this Team and the remedy (if one needs to be applied) may be quite different.