Self Organization Rules! By David Bulkin

The concept of self organization for agile teams is frequently discussed, with one excellent take being this from my colleague Sanjiv Augustine (which focuses on the question of whether agile teams need traditional management and how to apply light touch leadership).

This post focuses on simple practical rules (you may call them practices) for self organization.  Every team is different, so these are just samples but I believe they provide a practical perspective that I have not seen enough of (please comment if there are other posts that provide practical guidance on self organization).

Sample Rules (or Practices)

1. As a team member, I will contact the ScrumMaster if we can tweak a user story, to maintain its business value, while reducing time, cost or risk associated with implementing that user story.
2. As a team member, when I complete my work, on a task, I will either help another team member, or start a new task, depending on what will most likely allow us to deliver the maximum value in a Sprint.
3. As a team member, I will provide honest and open feedback to my peers, to the ScrumMaster, to the Product Owner, and all team members, whenever that feedback will help the performance of the team, even when I feel uncomfortable doing so.
4. As an agile team, we will define and continually refine rules and practices and use them to guide us in our work.

In Closing

Hopefully this short post was of value to you and your team. As a reminder, other than number four, these rules are just samples, so have fun creating your own and write back to tell us what they are and how they are working.  Also comment if you have seen other blog posts that cover practical rules for self organization on an agile team.

Agile Requirements Breakdown Structure by David Bulkin

In agile when we talk about requirements, we often talk about epics, features and user stories.

But, do we really know how these different levels of requirements fit together, and how they relate to vision, goals and outcomes?

This post provides a simple example of what a requirements breakdown can look like.  This is nothing new and is similar to a functional breakdown structure, or product oriented work breakdown structure that has been used since I started my career over 25 years ago.


An Example

It Starts with a Vision

At the top of the hierarchy is a vision.  The vision is broad in scope and addressing it can take many years and many projects.  In this example, our vision is:

Be the eBanking Provider of choice for small business customers

Goals, or if you like, Outcomes

To address our vision we have goals, or if you like outcomes (more below).  In this example, the goal / outcome is:

Increase retention on eBanking Website

You could make this more concrete, and thus turn it into an outcome, by including a measurement, stating something like:

Increase retention of small business eBanking customers by 20% as measured by…

Epics, Cohesive, Large Chunks of Business Value

Below the goals we have epics, which are large grained chunks of business value, that, by definition, will take more than on iteration to complete.  In fact, epics can be so large that they may take several releases to complete.  In this example, the epic is:

Add a Customer Center for self service for common needs

Note that even though this is an epic, you could still write it in user story format, perhaps like this:

As a customer
I want to handle my self service needs online
So that I can address them 24 by 7 by 365 without leaving the house or making a call

Features, Cohesive, but Smaller Chunks of Business Value

At the next level down are features, which in this model, are cohesive chunks that address a particular need.  In this model, features are smaller than epics and it often possible to complete a feature in a single release or even in one iteration.  In this case our feature is..

As a customer find a branch location

The Stories

At the lowest level of the hierarchy are the actual stories.  In this example the stories were split from the “find a branch” feature.  Here is one.

As a customer
find a branch that is close to a specific address
so that I can minimize travel

In real life there would likely be similar stories, such as finding a branch by hours of operation, or by zip code.


In Closing

There are number of variations on decomposition for requirements, and although this example is not comprehensive, I think a picture is worth a 1,000 words.

You can also check out other blogs that cover similar topics.  Dean Leffingwell covered this in a comprehensive white paper you can get from his site.

Drew Jemilo’s blog specifies a very similar take.  I would have never have found it if I hadn’t talked to him a couple of months back, so check it out at his blog.

Enjoy.