Product Backlog Items are brief descriptions of a feature or function. Usually they are short enough that they could be hand-written on a small note card. This brevity is meant to be just enough information so that the Product Owner and the team can use the PBIs as invitations to conversations. The resulting conversation (ongoing, evolving and involving the whole team and stakeholders) and the shared understanding that comes from that conversation is where the real value of the PBI resides. Part of the conversation occurs when the Product Owner initially writes the PBI so that the team can estimate the effort of building it. Part of the conversation is the actual work being done during a Sprint. Another part of the conversation is during the Sprint Review when stakeholders see the results of the team building the PBIs. If one creates PBIs as detailed specifications then we are essentially handcuffing the team into a set path and a prescriptive solution. The reason we hire qualified people onto our Scrum Team is for their knowledge, experience, and problem solving abilities. If we lock them into a set path, then we are literally turning them into cogs in a machine to spit out specific code. PBIs that are invitations to conversations allow them the flexibility to figure out how to solve the problem by engaging in a conversation on what is needed.
Affiliated Promotions:
Please share!
“If one creates PBIs as detailed specifications then we are essentially handcuffing the team into a set path and a prescriptive solution.”
To some degree I can concur with this statement, however there are a multitude of scenarios that I can think of that equally would qualify as required specific solution paths and coding conventions.
Coding standards, make post-analysis and support easier. These same standards ensure that there exists a common understanding of code without having to understand 5 different ways of doing something. Object oriented development in a sense that things become modules.
If the goal is to produce a lego house that operates and is structured similarly to the house next to it… we don’t build the windows, doors and walls and windows all over. We have them pre-assembled or have a pre-assembly guide to expedite the process. Where the innovation comes in is the core of the solution. This often is unique and where special problem solving skills are required. The items on the fringes should be modular and compartmentalized so that effectively these become bolt on services or near bolt on services/functionality.
“The reason we hire qualified people onto our Scrum Team is for their knowledge, experience, and problem solving abilities.”
Further the above point is a very wishful desire, especially in this day and age of off-shoring work where the desire is the bottom line and not necessarily the quality or quantity of work provided.
In short, in an ideal scenario, I think you are closer to right but I suspect it doesn’t fit reality as often as desired.
Hi Barry,
Glad to have you back!
The point of the phrasing you have indicated is not for a team to “re-invent the wheel” for each and every PBI. Instead, the team uses their “knowledge, experience and problems solving abilities” to determine, for example, if there is a pattern to be applied, a solution to buy (instead of build), a research project to truly invent something new, or just use day-to-day good coding practices, etc. The other part of this that is perhaps only implied in this explanation is that the Product Owner is NOT authorized to impose a solution on the team and in fact is generally advised to stay out of technical discussions. The solution to the PBIs is determined by the team collectively, free from outside authority to impose a solution. Things like coding standards and the like can certainly be adopted by a team, but it is the team’s collective choice to do so. This process is actually encapsulated in how a team develops their Definition of “Done”… which I will be writing an in-depth article about later on 🙂
Your last comment is actually part of what Scrum is all about: it is an ideal that a team aspires to achieve… not a set of practices that a team picks and chooses from! That ideal is meant to cause ripples (and sometimes earthquakes) through an organization to transform it into a hyper-performance product development organization. There are enough examples of organizations large and small doing just this that it is not an unachievable ideal… but it can be very very difficult!
Thanks again for your comments and questions.
Ty again.