The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.
Posted by admin under Uncategorized
Lately, our discussions here have focused on scaling Scrum for the enterprise. That is, we’ve been thinking bigger and moving away from some of the fundamental issues pertaining to Scrum and team dynamics. But a reader request reminded me that not everyone is focusing on translating the benefits of small team Scrum for the largest, most complex development environments. So let’s get back to the basics and consider a more introductory topic: the Product Backlog Item.
The Product Backlog Item (or “PBI,” “Backlog Item,” or sometimes simply “Item”) represents all the work a team needs to complete. However, since Scrum utilizes an incremental and iterative approach to development, only a handful of these PBIs are tackled by the team in a given sprint.
Because it is the primary responsibility of the Product Owner to determine what work will yield the most business value, it is also his or her duty to prioritize the PBIs. That is, each sprint, the Product Owner determines which PBIs a team will attempt to complete within the sprint. This is often referred to as the Product Owner dictating the “what” (i.e. what is to be delivered by the end of the sprint), while the “how” is left for the team to decide. That is, the team decides “how” to complete its PBIs—in what order, which team members will work on specific Items, etc.
During the sprint, Tasks are defined for each PBI, so that the Team has a clear sense of how it will accomplish its work. It is important to note that the Product Owner should not be monitoring their progress at the Task level. Rather, Tasks are simply more granular versions of the work entailed to complete a PBI. As such, they are created for the benefit of the team—both in terms of sizing up their PBIs in a realistic manner and ensuring the Team knows what everyone is doing to complete Sprint goals.
It is important to note that PBIs are estimated using Story Points—i.e. abstracted estimates of difficulty—whereas Tasks are estimated with hours. Since these two forms of estimation are completely unrelated, PBIs and Tasks should not be compared; they are separate entities.
As a best practice, PBIs should always be estimated using a consistent scale of Story Points. These points can be anything—factors of two, t-shirt sizes, dog breeds, headaches, etc.—but what is important is for the team to agree upon their scale, the approximate values of each estimate within the scale, and use them consistently.
Tasks, on the other hand, should employ hour estimates. Most developers are comfortable estimating the number of hours they believe it will require to complete a given Task. However, some advanced Scrum teams prefer not to assign hour estimates to their Tasks. Instead, they simply mark their Tasks as “done” or “not done,” which means the corresponding report would track Tasks remaining, rather than hours. In ScrumWorks Pro, all meaningful, long-term metrics rely on PBI estimates, not those associated with Tasks.
Leave a Reply
Scrum Training Series
- Do you REALLY want to learn Scrum? Try a 3.1-day CSM class with case studies. July 25, 2013
- Scrum based funding model – 20 percent May 9, 2013
- MJは６月と７月の２ヶ月間、日本に滞在する予定です。スクラムのコーチングまたはトレーニングに興味のある方は是非ご連絡ください。 March 14, 2013
- The Next Big Idea March 5, 2013
- On Being Available February 17, 2013