The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.


The CSM Exam

Posted by admin under Agile and Scrum, Scrum Discussion

Very soon, the Scrum Alliance will introduce a new process to certify ScrumMasters. Previously, certification has been awarded to anyone who attends a two-day, Scrum Alliance-certified ScrumMaster Certification course. But beginning October 1, course participants will also be required to pass an exam within 90 days of attending training. Certification will be good for two years. At the end of two years, individuals will need to re-certify for CSM status. This costs $150, including Scrum Alliance membership fees, and lasts two years.

In some ways, this marks an improvement because it endeavors to ensure that a CSM fully understands the tenets of Scrum. Certainly, this is better than simply awarding an individual ScrumMaster certification based on sitting through a two-day class. That is, while CSM courses are incredibly beneficial for most participants, they do not guarantee that an attendee will necessarily absorb or apply everything he or she has learned. Of course, the flipside is that an exam will only test attendees on certain aspects of the Scrum framework in a format that does not necessarily promote a deep understanding of Scrum’s values.

What do you think? Is this an improvement over the existing certification process or an unhelpful amendment to a process that was working fine? I’d love to hear your thoughts in the comments section.

You will do better on the CSM or PSM exam by keeping your Scrum Reference Card handy.

The Scrum Reference Card

The Scrum Reference Card

If you need to practice for the CSM exam (or others), try the free practice test towards the end of the Introduction to Scrum.
Scrum Quiz

Tags: , ,


Back to Scrum Basics: Product Backlog Items vs. Tasks

Posted by admin under Uncategorized

The Product Backlog is a force-ranked list of Product Backlog Items (PBIs), which should represent customer-centric product features. The Product Backlog should not contain tasks.

Since it is the Product Owner’s responsibility to determine what work will yield the most business value, the Product Owner prioritizes the PBIs. The Product Owner focuses more on the “what,” while the “how” is left for the team to decide.

The Product Owner and team should collaborate about an hour per week on backlog refinement (aka “backlog grooming”) to convert large fuzzy requirements (“epics”) into more distinct user stories. If a PBI would take more than a quarter of a two-week Sprint, it’s probably too big.

Only a subset of these PBIs, the Sprint Backlog, are tackled by the team in a given Sprint. During Sprint Planning, and during the Sprint itself, the team discovers and tracks the Sprint Tasks necessary to accomplish each PBI in the Sprint Backlog. I often meet teams that cannot distinguish their Sprint Backlog from their Product Backlog, making me wonder whether they have clear goals.

My favorite way to keep track of Sprint Tasks is with a physical taskboard, owned by the team. The team is less likely to self manage if people outside the team, including the Product Owner, try to scrutinize their progress during the Sprint, particularly at the Task level. The demo at the Sprint Review Meeting is a more appropriate time to inspect and adapt the product.

If the effort to accomplish PBIs is estimated, we prefer relative units such as T-shirt sizes or Story Points—i.e. abstracted estimates of difficulty. Sprint Tasks should usually take one day or less. Some teams find it useful to estimate Sprint Tasks in hours, though we eventually stopped estimating them at all. Also, there’s no point in trying to reconcile the effort estimates of PBIs and Sprint Tasks.


Watch a team break Product Backlog Items (PBIs, or User Stories) into Sprint Tasks during the Sprint Planning Meeting.


Tags: , ,


Value Versus Velocity

Posted by admin under Agile and Scrum, Scrum Basics, Scrum Discussion

Over at InfoQ, Vikas Hazrati points out the common misconception that a team’s velocity is directly linked to the value it yields for the organization. It’s a fairly understandable mistake: If a team accomplishes more in a given sprint, then surely it’s making a larger contribution to the organization’s success, right? Well, not necessarily… A team might set records for the number of story points it completes, but that doesn’t actually mean it’ll add up to “value” for the organization. For instance, what if the product it completes sits on the shelf and is never shipped because evolving market conditions render it irrelevant? What if it is shipped, but no one buys it? It’s easy to see that, once these aspects are considered, there’s really no connection between velocity and value.

Determining what agile-specific metric is best for quantifying the actual value generated through the team’s work has been a point of ongoing frustration for many managers. The best way I’ve seen this issue dealt with is in the ScrumWorks Pro tool, which employs several metrics—Business Value and Earned Business Value—to give organizations a way to track the actual business value being created in a product.

How does your organization track this? I’d be curious to hear your strategies for this in the comments section. Thanks!

Tags: , ,


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 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.

Tags: , , , ,