Scrum Methodology

Free Scrum Webinars

Posted by admin under Scrum Basics, Scrum Discussion, Uncategorized

I recently attended a webinar hosted by Scrum company Danube Technologies. The session, called “Definition of Done: An Organizational Perspective,” was led by Dr. Dan Rawsthorne, PhD, one of Danube’s Certified Scrum Trainers. Over the course of an hour, Rawsthorne discussed creating and revising acceptance criteria for various kinds of user stories and how those stories can be used as standardized templates as well as an educational tool within a Scrum organization. In all, it was a great webinar; Rawsthorne clearly speaks from years of experience.

Sound like something you, your team, or your company could benefit from? Check out the entire list of special event webinars offered by Danube. They’re free and always hosted by a Certified Scrum Trainer. There’s a chunk of time at the end reserved for questions and, importantly, there’s no sales pitch. Highly recommended.

Back to Scrum Basics: Product Backlog Items vs. Tasks

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.

Tags: Product Backlog Items, Scrum Basics, Tasks

Scrum and the Enterprise

Posted by admin under Uncategorized

As Scrum continues to grow in popularity, one of the hottest topics on the minds of the community is how to translate the benefits of a paradigm created for small, collocated teams for enterprise-level installations of hundreds, if not thousands of users. Given that communication channels increase (and therefore communication decreases) as the size of a team grows, this issue is only compounded when teams begin to scale to Scrum-of-Scrum configurations. Clearly, the solution is a tool designed specifically for Scrum projects that can allow teams to remain small, but nonetheless connected to the bigger picture.

Of course, the tool also needs to be flexible enough to meet the unique demands of large and complex development environments. For example, large organizations often develop products with shared components, which require the ability to plan releases against multiple backlogs. And while Scrum and other agile management methods have steadily crept into the software development landscape, the project management tools available have not kept pace.

But all that may be changing now. I just watched a screencast of ScrumWorks Pro 4 (you can watch it, too, here: http://danube.com/sw_flash/release-4/) and this release’s new functionality makes it the first truly enterprise-ready Scrum tool. Namely, it addresses the issue outlined above by allowing customers to manage high-level features and releases that span multiple product backlogs. This is a really important breakthrough. Before that functionality existed, organizations had to creatively develop workarounds for their agile tools to achieve the same effect, but, still, with less-than-ideal results. Now, products can be associated with multiple programs, which, in turn, allows shared components to be modeled accurately while providing organizations with a more realistic view of overall progress. This is going to eliminate some very big headaches for some very big companies… You can read more about it here.

Scrum Users Group Update

Posted by admin under Uncategorized

If you missed our original post on this topic, InfoQ has published a follow-up to the Scrum Users Group controversy here. After the Scrum Alliance issued a notification to Scrum users group nationwide that it held rights to the use of the phrase “Scrum users group,” a wave of confusion ensued. The Alliance’s Cory Foy weighed in on our comments section to better explain what was happening. It seems that Foy has now been appointed “community liaison” and will interface with the various users groups to help Scrum continue to flourish on a grassroots level. Key to this outreach effort is an inclusive mailing list to get the word out about events and groups, while generally fostering a dialogue focused on Scrum. Sounds like the situation’s definitely improving, but InfoQ reporter Mark Levison still concludes his article by wondering if anything’s really changed.

This seems like a step in the right direction to me. What do you think?

A Career In Scrum

Posted by admin under Scrum Discussion, Uncategorized

As Scrum’s popularity increases, there is a rising demand for professionals with Scrum experience. However, since Scrum is still a fairly new management method, that puts many aspiring Scrum practitioners in a tough spot: They want the experience of working in a Scrum environment, but they need Scrum experience to get the job. Obviously, then, there is no better experience than actually working in a Scrum environment, but there are plenty of ways to build experience that will pay off in that environment.

One way to secure valuable experience is to attend a two-day Certified ScrumMaster (CSM) course. CSM courses focus on an interactive approach to learning the basics of Scrum, including its vocabulary, principles, and practices. The course lasts only two days, but most attendees find that the information covered really sticks due to the hands-on nature of the course. Several companies offer CSM courses and a full list of trainers and their schedule of courses is located on the Scrum Alliance website.

Of course, real life experience working in a Scrum environment is far more compelling than simply attending a CSM course. When an individual works on a Scrum team—whether as a ScrumMaster, Product Owner, Analyst, Developer, Tester, etc.—for a full year since completing a CSM course, he or she may apply to become a Certified Scrum Practitioner (CSP). The Scrum Alliance reviews and, based on one’s qualifications, approves the CSP designation. Clearly, the CSP title is attractive for employers, who view it as proof that an individual understands Scrum’s principles and processes and has practiced them.

Short of getting experience on a Scrum team, the next best thing is to illustrate to your prospective employer that you possess qualities valued within a Scrum environment. These might include skills such as pair-programming, test-driven development, continuous integration, and refactoring code. Apart from these development techniques, it’s important to demonstrate a strong background in collaboration and facilitation. Since Scrum places greater emphasis on the success of the team, rather than personal heroics, an individual who has proven his or her leadership potential—without extensive authority—would be an excellent candidate for the ScrumMaster role.

Beyond Scrum courses or, of course, working in a Scrum environment, an individual can prepare for a career in Scrum by developing certain skill sets and demonstrating personality attributes that would fit within the Scrum paradigm.