Scaled Agile Framework: I Learned about Weighted Shorted Job First (WSJF)

Among the great things I learned last week in London UK at the Scaled Agile Framework (SAFe) Program Consultant training is the concept of using the Weighted Shortest Job First method of prioritization for backlog items.  The concept is similar to the Relative Return On Investment (RROI) that I teach in my Certified ScrumMaster and Certified Scrum Product Owner courses, but adds a bit of sophistication both in the background theory and in the actual application.

Weighted Shortest Job First is a numerical score where the larger the score, the sooner the job (feature, product backlog item) should be done.  Scores therefore give a sequence to jobs.  The score is based on the ratio between two estimates: the estimate of the “cost of delay” and the estimate of the “duration to complete”.  The cost of delay is a more sophisticated version of business value in that it takes into account customer needs, time criticality and risk reduction or opportunity cost.

In SAFe, the WSJF is calculated at the level of the team’s backlog on user stories through estimates of effort by the team and estimates of the cost of delay that are done by the product owner in collaboration with program management and business owners.  The effort estimate is considered a reasonable proxy for the measure of duration, but there is explicit acknowledgement that this may not always be a reliable relationship.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Book List for Enterprise Agile Transformations

Leaders of Agile Transformations for the Enterprise need to have good sources of information, concepts and techniques that will guide and assist them.  This short list of twelve books (yes, books) is what I consider critical reading for any executive, leader or enterprise change agent.  Of course, there are many books that might also belong on this list, so if you have suggestions, please make them in the comments.

I want to be clear about the focus of this list: it is for leaders that need to do a deep and complete change of culture throughout their entire organization.  It is not a list for people who want to do Agile pilot projects and maybe eventually lots of people will use Agile.  It is about urgency and need, and about a recognition that Agile is better than not-Agile.  If you aren’t in that situation, this is not the book list for you.

Culture

These books all help you to understand and work with the deeper aspects of corporate behaviour which are rooted in culture.  Becoming aware of culture and learning to work with it is probably the most difficult part of any deep transformation in an organization.

The Corporate Culture Survival Guide – Edgar Schein

Beyond the Culture of Contest – Michael Karlburg

The Heart of Change – John Kotter

Management

This set of books gets a bit more specific: it is the “how” of managing and leading in high-change environments.  These books all touch on culture in various ways, and build on the ideas in the books about culture.  For leaders of an organization, there are dozens of critical, specific, management concepts that often challenge deeply held beliefs and behaviours about the role of management.

Good to Great – Jim Collins

The Leaders’ Guide to Radical Management – Steve Denning

The Mythical Man-Month – Frederick Brooks

Agile at Scale

These books discuss how to get large numbers of people working together effectively. They also start to get a bit technical and definitely assume that you are working in technology or IT. However, they are focused on management, organization and process rather than the technical details of software development. I highly recommend these books even if you have a non-technical background. There will be parts where it may be a bit more difficult to follow along with some examples, but the core concepts will be easily translated into almost any type of work that requires problem-solving and creativity.

Scaling Lean and Agile Development – Bas Vodde, Craig Larman

Scaling Agility – Dean Leffingwell

Lean Software Development – Mary and Tom Poppendieck

Supporting

These books (including some free online books) are related to some of the key supporting ideas that are part of any good enterprise Agile transformation.

Toyota Talent: Developing Your People the Toyota Way – Jeffrey Liker, David Meier

Agile Retrospectives – Esther Derby

Continuous Delivery – Jez Humble, David Farley

The Scrum Guide – Ken Schwaber, Jeff Sutherland, et. al.

The OpenAgile Primer – Mishkin Berteig, et. al.

Priming Kanban – Jesper Boeg

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Evolution of a Scrum Diagram

Over the many years that I have been teaching Scrum (since 2005!), I have had a diagram of Scrum as part of my slides and/or handouts.  The diagram has gone through several major and minor changes throughout that time.  Here is the progression from oldest to newest:

First Attempt

This diagram was used in some of my earliest slides when I first started delivering Scrum training.  It is bad.  It is woefully incomplete.  But, here it is:

01 Scrum Process Diagram

Second Diagram

I knew the first one was bad so after not too long, I created this next diagram as a supplement that was meant to show the whole Scrum process all in one page. Similar to other Scrum “cheat sheet” style diagrams. I used this diagram until about 2008 when I got some very good feedback from a great trainer, Jim Heidema.

02 All of Scrum Diagram

Third Try

The changes I made were small, but to me, significant.  Changing from a “mathematical” language of “Sprint N”, “Sprint N+1″ to a more general language of “Current”, “Future” was a big deal.  I really struggled with that.  Probably because I was still relatively new to being non-technical.

03 All of Scrum Diagram

Diagram Four

This fourth diagram made some minor formatting changes, but most importantly added “Backlog Grooming”.  It’s funny how long I talked about grooming in my classes before realizing that it was missing from the diagram.  I used the previous diagram and this diagram for a couple years each before making a rather major change to create the next one.

04 All of Scrum Diagram

Fifth Go

A couple years ago I realized that I wasn’t really talking about the Scrum values in my classes.  I started to introduce them in some of my other handouts and discussions, but it still took a while for me to reflect those values in my diagram.  I had also received a lot of feedback that having two Product Backlogs in the diagram was confusing.  Finally, I realized that I was missing an opportunity to use colour more systematically.  So, a major reformatting, systematic colour coding and the addition of the Scrum values was my next change.

05 All of Scrum Diagram

Branded Diagram (ug.)

In a rush, I added some logos to the diagram. Just made it gross, but it’s badness, combined with feedback about said badness, actually inspired a major change for the next version.

05 All of Scrum Diagram - Branded

Newest Diagram

Literally just a week ago, I was showing my brand-new branded diagram to a bunch of people who really care about design and UX.  The very first comment when I handed out the diagram was: “wow, you can really tell this wasn’t done by a designer!”  Well, that got me thinking deeply about the diagram (again).  So, here is my newest, latest and greatest (still not done by a designer) version of my Scrum diagram!

06 The Scrum Process

The Future

I would absolutely love constructive feedback about this latest diagram. Of course, if you like it, please let me know that too! The thing I like about this is that it is a way of looking back at almost 9 years of my teaching history. Continuous improvement is so important, so I welcome your comments! If you have your own diagrams, please link to them in the comments – I would love to see those too! In fact, it would be really cool if a bunch of people could make little “Evolution of a Scrum Diagram” posts – let me know if you do!!!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Ranking: the Best and Worst Roles to Transition to ScrumMasters

So you’re trying to do Scrum well because you heard it gave you great results.  You know that the ScrumMaster role is critical.  How do you find the right people to fill that role?  Here is a list of several roles that people commonly leave to become ScrumMasters, and a few not-so-common roles as well, all ranked by how well those people typically do once they become ScrumMasters.  From Worst to Best:

  • Worst: PMI-trained Project Managers (PMPs).  Too focused on control and cost and schedule.  Not easily able to give teams the space to self-organize.  Not able to detach themselves from results and focus on the process, values and teamwork needed to make Scrum successful.
  • Bad, but not awful: Functional Managers.  The power dynamic can be a serious hindrance to allowing teams to self-organize.  But, good functional managers already are good at building teams, and empowering individuals to solve problems.
  • Bad, but not awful: Technical Leads.  Here, the biggest problem is the desire to solve all the team’s technical problems instead of letting them do it.  Now, instead of detachment from results (project managers), it’s detachment from solutions.
  • So-so: Quality Assurance people.  Good at rooting out root-cause for problems… just need to shift from technical mindset or business mindset to cultural and process mindset.  Another problem is that QA is not nearly as respected as it should be and QA people typically don’t have a lot of organizational influence.
  • So-so: Junior techies: Enthusiasm can make up for a lot of gaps and naiveté can help solve problems in creative ways, but there will be a huge uphill battle in terms of respect and influence in an organization.
  • Good: non-PMI-trained Project Managers: rely on teamwork and influence rather than tools, processes and control (of course there are exceptions).
  • Awesome: Executive Assistants.  Respected and respectful, use influence for everything, know everyone, know all the processes, know all the ways to “just get it done”. Of course, they don’t usually know much about technology, but that often turns out to be good: they don’t make assumptions, and are humble about helping the technical team!

The ScrumMaster creates high performance teams using the Scrum process and values.  The ScrumMaster is not accountable for business results, nor project success, nor technical solutions, nor even audit process compliance.  The ScrumMaster is responsible for removing obstacles to a team’s performance of their work.  The ScrumMaster is an organizational change agent.

Other things you might want to consider when looking for a ScrumMaster:

  • Does the person have experience managing volunteer groups?
  • Does the person have good people skills in general?
  • Does the person want to create high-performance teams?
  • Can the person learn anything – business, process, technical, people, etc.?

Bottom line: try and avoid having PMI-trained project managers become ScrumMasters.  Even with good training, even with time to adjust, I often find that Scrum teams with PMI-trained project managers are always struggling and almost never become true teams.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Agile Framework: Agile Values and Principles, The Agile Toolkit, The Agile Organization

When I am speaking with executives, ScrumMasters and other leaders of change in organizations, I often present a simple 3-layer model to understand the relationship between the various moving parts in the Agile Framework:

  1. The Agile Values and Principles – These describe the culture and, in the Agile Manifesto, are the definition of the word “Agile” as applied to software development. I didn’t write the Agile Manifesto so I don’t get to re-define the word Agile.  To give an example: in the manifesto it says “The best architectures, requirements and designs emerge out of self-organizing teams.”  As a former enterprise architect at Charles Schwab, I struggled with what I saw as incredibly wasteful up-front architectural activities when I knew that developers would (sometimes) ignore my glorious ivory-tower plans!  Therefore, if you are still doing up-front architecture and forcing your teams to comply to that architecture, you aren’t Agile.  Therefore, as an individual, a team or an organization, you need to make a conscious decision to “BE” Agile or not… and if you decide not, then please don’t call yourselves Agile.
  2. The Agile Toolkit – There are many hundreds of distinct tools in the Agile toolkit including Scrum, OpenAgile and other “large” Agile methods, as well as the Planning Game, Product Box, Test-Driven Development and other “small” Agile techniques.  Any group of people trying to BE Agile, will need to use dozens or even hundreds of different Agile tools.  I call them tools because the analogy with construction tools is a very good one.  Scrum is like a hammer.  But you can’t do much with just a hammer.  Scrum is a great, simple tool.  But you always need other tools as well to actually get stuff done.  All the tools in the Agile Toolkit are compatible with the Agile Values and Principles.  Even so, it is possible to use the Agile Tools without being Agile.  A Scrum team that never gets together face-to-face is not an Agile team: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”  (Video conferencing doesn’t count.)
  3. The Agile Organization – When you start using a tool, there is a learning period.  We start by being conscious of our incompetence and as we persist, we become competent… but it isn’t natural or habitual yet.  Eventually, with continued use, we become unconscious of the tool.  IDE’s and version control are like this in most organizations: we don’t even think about them!  But getting through that initial stage requires us to change; to develop new skills.  This process usually requires discomfort or pain (including psychological pain).  An organization attempting to BE Agile and to use many of the tools in the Agile Toolkit will need to make many changes and often these will be difficult.  For example, incorporating the Product Owner role from Scrum into your organization requires new role definitions, new performance evaluation practices and criteria, new compensation systems, new communication and reporting mechanisms, new authority and accountability processes, etc. etc.  All of the changes required are about creating Enterprise Agility throughout the whole organization, beyond just software or IT.  These extensive changes are often started in a very ad hoc manner, but at some point they need to become systematic.  This is an important decision point for executive management: are we going to be Pragmatic about our Enterprise Agile adoption, or are we going to be Transformative about our Enterprise Agile adoption.

All of this is summarized in this graphic:

The Agile Framework [PDF]

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Real Agility Program – Recommendations (Assessment and Playbook)

Recommendations IconWe have already written about how Leadership and Delivery Teams operate in a Real Agility Program.  It’s time to look at our Recommendations component: getting started on the right path for Real Agility.

Recommendations = Assessment + Playbook

In the assessment portion of the Recommendations component, we gather information about the current situation at an organization.  This includes everything from detailed practices, processes and tools, to strategies and organizational culture.  This assessment work is designed to help everyone understand the organization’s current gaps, and what strengths it has that will best support it to cross those gaps to Real Agility.  The Assessment includes an online portion, an on-site portion and an off-site portion.  The assessment work naturally leads to the development of the playbook.

The online assessment requires that each person throughout an organization complete an online survey about corporate culture.  It includes three major sections: existing challenges, sense of urgency, and level of teamwork.  This cultural survey is the foundation of understanding how to be successful with Real Agility.  Managers and leaders are also asked to complete an additional questionnaire about the current environment at the organization.  This includes high-level information about the structure of the organization, client and vendor relationships, and staff.  Additional surveys may also be administered to understand other aspects of the organization.  For example, in an organization that is struggling to use Scrum, we will often use the Scrum Team Assessment.

The onsite portion of the assessment combines in-person interviews and workshops with staff and managers.  Interviews explore aspects of the corporate work environment in more depth and include questions about familiarity with Agile methods, and obstacles that people might see to adopting Agile.  The workshops gather data around current challenges and strengths, success criteria for projects, situational analysis for teams, and existing metrics (or lack thereof).  Typically we need a meeting room committed to our consultants for doing interviews.

The offsite portion of the assessment is used for us to evaluate and analyze the survey, interview and workshop results.  We also use some time to review any relevant documentation such as process templates, org charts, governance requirements, etc.  We may also use some of this time for follow-up phone calls or emails to clarify aspects of the assessment results.  Finally, this offsite work is also where we do the bulk of the development of the recommendations in the playbook.

Several aspects of our assessment are based on the OpenAgile Catalyst Assessment Tools which are open-source and can be found online.  We also have a number of proprietary tools.

The playbook maps out a path to a successful Real Agility transformation.  It is a road map that helps leaders, managers and team members make good business decisions as they strive for Real Agility.  The playbook aids the organization to effectively and appropriately launch Real Agility teams: management teams, project teams, and operational teams.  The Real Agility Program playbook includes analysis of the assessment results, recommendations for work that the organization can do on its own and suggests outside assistance that enhances Real Agility results.  Two critical questions that are answered in the Playbook include:

  • What Agile method or methods should we be using and why?
  • What organizational change approach should we take and why?

We deliver the recommendations in the form of the playbook and an executive summary slide deck in an iterative and incremental fashion so that stakeholders can give us early feedback and so that we can adapt our assessment agenda as we go along.  The recommendations include ideas about organizational structure, staffing, governance changes, departmental relationships, tooling, and many other aspects of how an enterprise can best become and Agile enterprise.

Following the Recommendations in the Real Agility Program playbook results in huge time-to-market improvements, 200% (or better) productivity boost for delivery teams, and extremely satisfied customers and staff.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

“Meet: Scrum”, the Diagram

Recently, in my work helping teams to learn and implement Scrum, I have deliberately not been using diagrams.  Having participants create their own ways of describing Scrum based on their own understanding is often a much more powerful approach to learning than showing them a diagram.  If you give someone a map, they tend to assume that all of the exploring has already been done.  If you give them a space to explore, they tend to create their own maps and provide new knowledge about the space being explored.  Maps and diagrams do serve a purpose.  They are useful.  What’s important to always keep in mind is that they should not be regarded as definitive but rather as one  contribution to a body of knowledge that can and should grow.

Anyhow, this isn’t intended to be a blog post about diagrams but rather as a post sharing a diagram that I have created.  One of the participants of a Scrum training that I recently facilitated asked me for a diagram and I said I would find one for him.  All of the other diagrams out there that I could find didn’t exactly convey my own understanding of Scrum.  So, I decided to create my own.

This is the first increment.  I am open to feedback and I look forward to finding out how this interacts with others’ understanding of Scrum.

ScrumDiagramTravisBirch

You can download it at this link: Meet: Scrum.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Great little presentation on Retrospectives… and a bonus download!

If you are a ScrumMaster or Coach or Project Manager or Process Facilitator of any kind, I encourage you to become a master of Retrospectives.  I just happened upon this great little set of slides and presentation notes about Retrospectives by a couple of people, Sean Yo and Matthew Campbell, done a couple months ago.  Very helpful with some practical information, some great links… I strongly recommend checking it out.  My only concern is that they limit the scope of retrospectives too much.  I have a list of topics that I think can and should be considered in a retrospective:

  • Technology / tools
  • Work space / physical environment
  • Corporate culture
  • Corporate standards and policies
  • Teamwork
  • Work planning and execution
  • Skill sets
  • Interpersonal dynamics
  • External groups
  • Personal circumstances and needs
  • The process you are using

 

This list comes from a presentation I used to include as part of my Certified ScrumMaster course.  (Now, in my course I teach three specific methods of doing retrospectives as part of an in-depth simulation exercise.)  Here is a PDF version of the Retrospectives Module.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Updated: Agile Estimation with the Bucket System

I have added a pdf download of this article about Agile Estimation with the Bucket System.  It’s just a handy, nicely-formatted document that can be used for quick reference.  It is now part of the materials I give out for my Certified ScrumMaster training classes.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Real Agility Program – Leadership Transformation Team

Leadership IconOne of the main components of our Real Agility Program for enterprise Agile transformations is the Leadership Development track.  This track is a series of monthly leadership meetings with one of our consultants to help them establish their Leadership Transformation Team.  This team is based in part on the concept of a guiding coalition from John Kotter’s work (see “Leading Change“), and in part on Edgar Schein’s work on corporate culture (see “The Corporate Culture Survival Guide“) as well as our own specific experience on successful Agile transformations in organizations.

The very first thing, of course, is to establish who should be on the Leadership Transformation Team.  There are six major categories from which the team must find representatives:

  1. The Executive Sponsor, for example the CIO
  2. Business Management, for example an SVP of Sales or Product Development
  3. Process Management, for example the head of the PMO or Compliance
  4. Technology Management, for example VP of Technology or Development
  5. Human Resources, for example a Director of Staff Development and Training
  6. and Apprentice Agile Coaches / Agile Champions

In total, the number of people on this team should be no more than 12, but smaller is better.

Once established, this Leadership Transformation Team must execute on three core responsibilities in perpetuity:

  1. Urgency and Vision: constant, strong, repetitive, prominent communication of the reasons for change and a high level view of how those changes will happen.
  2. Lead by Example: use of an Agile approach to run the Leadership Transformation Team’s work – we recommend OpenAgile for the process, but Kanban may also be used.
  3. Empower Staff: focus on removing obstacles by making structural changes in the organization, helping staff master standard Agile processes and tools, and eventually, creating innovative Agile approaches customized for the organization.

This leadership support is a critical success factor for an Agile Transformation.  One of the first steps in our program for this team is to help with the creation of the team’s plan for the transformation.  This plan can be derived from an number of sources including assessment work, but includes a number of standard items that must eventually be addressed for a successful transformation.  At a high level, these include:

  • Hiring, performance evaluation and compensation
  • Reporting relationships
  • What to do with project managers, business analysts, testers and certain middle managers
  • Key metrics and processes for measuring progress
  • Technology and physical environment
  • Vendor relationships and contracts
  • Compliance, regulation and documentation

Many of these items are multi-year change efforts that need to be closely guided and encouraged by the Leadership Transformation Team.

One final point about the Leadership Transformation Team needs to be made: the work they do must not be delegated to subordinates.  If something is part of their three core responsibilities, it must be handled directly by the members of this team.  Therefore, the team members need to allocate a significant percentage of their time to the effort.  Usually 20% is sufficient to get started.  The proportion may wax and wane slightly over time, but if it gets too low, the Leadership Transformation Team will lose touch with the transformation and the risk of it going bad increases substantially.

See also our article about the Recommendations component of the Real Agility Program.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

User Stories and Story Splitting

In Scrum and other Agile methods, a common way to manage feature requests is with User Stories.  I’ve been teaching people about User Stories and doing workshops with teams for a long time.  Out of that work, I’ve created a very simple PDF User Stories and Story Splitting reference sheet that might be handy.  Please feel free to download it and share it.  This document is something that I explain in-depth in my Certified Scrum Product Owner training seminars.

There are a number of sites out there that include some details that are left out of the reference.  Please see, for example, “Patterns for Splitting User Stories” by Richard Lawrence.  See also the great foundational article on “INVEST in Good Stories” by Bill Wake.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: Agile Coaching Patterns Wiki

Coaches for Agile teams and organizations is a growing profession.  I’ve been coaching for a long time, and I’ve used/invented/learned-about many different techniques or interventions for coaching in the context of Agile teams.  I have recently started a Wiki to capture some of this information.  (Originally, I was hoping to write a book, but I don’t have the time to do it on my own or even to coordinate a multi-author effort.)  This is an open invitation to participate in the wiki.  I won’t make it fully open (like wikipedia), instead, it will be by invitation.  Connect with me on LinkedIn and mention you would like to contribute, and I will set you up with an account… and then you can go nuts :-)  If there end up being several contributors, I’ll make a block on the front page for links to contributors and/or their organizations.

Check out the Agile Coaching Patterns wiki.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Estimation with the Bucket System

Estimation – The Bucket System [pdf] – printable reference version of this article.

The “Bucket System” is a way to do estimation of large numbers of items with a small to medium sized group of people, and to do it quickly.  The Bucket System has the following qualities which make it particularly suitable for use in Agile environments:

  • It’s fast!  A couple hundred items can be estimated in as little time as one hour.
  • It’s collaborative.  Everyone in a group participates roughly equally.
  • It provides relative results not absolute estimates (points vs. hours).
  • The results are not traceable to individuals and so it encourages group accountability.
  • Works with teams to estimate effort or with stakeholders to estimate value.

BucketSystem3

The Bucket System of estimation works as follows:

  1. Set up the physical environment as per the diagram below.  Ensure that all the items to be estimated are written on cards.
  2. Choose an item at random from the collection.  Read it to the group.  Place it in the “8″ bucket.  This item is our first reference item.
  3. Choose another item at random from the collection.  Read it to the group.  The group discusses its relative position on the scale.  Once consensus has been reached, put the item in the appropriate bucket.
  4. Choose a third item at random and, after discussion and consensus is reached, place it in the appropriate bucket.
  5. If the random items have clearly skewed the scale towards one end or the other, re-scale the items (e.g. if the first item is actually very small and should be in the “1″ bucket).
  6. Divide and conquer.  Allocate all the remaining items equally to all the participants.  Each participant places items on the scale without discussion with other participants.   If a person has an item that they truly do not understand, then that item can be offered to someone else.
  7. Sanity check!  Everyone quietly reviews the items on the scale.  If a participant finds an item that they believe is out of place, they are welcome to bring it to the attention of the group.  The group then discusses it until consensus is reached and it is placed in one of the buckets.
  8. Write the bucket numbers on the cards so that the estimates are recorded.

Bucket SystemSome important points to consider:

  • Multiple items can be in the same bucket.
  • Items cannot be placed “between” buckets to represent a more precise estimate.
  • If the distribution of the items is skewed to either end of the scale, then during the sanity check step the group should also discuss if the items can and should be spread out more evenly along the scale.  If so, then the group does it collectively.
  • The facilitator should watch to make sure that no one moves items that have already been placed until the “sanity check” step.
  • The division of items among participants does not need to be exactly equal – don’t worry about “dealing” out the items.  Instead, just divide them up roughly.
  • If the “divide and conquer” stage has one or two people working very slowly through their items, it is acceptable to suggest that they share their remaining items with people who are already finished.
  • It is not acceptable for an individual to completely abstain from the process.  If someone desires to abstain, they should be counselled that this means they will not have any future say in the estimates.
  • During the “divide and conquer” stage it is critical that absolute silence is maintained.  In particular, there should be no bilateral discussion of items.  This is to protect the anonymity of individuals placing items as much as possible.

The Bucket System

 

The bucket system is a good alternative estimation method to try instead of Planning Poker.  It is much faster than Planning Poker and still gets reasonable results.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I do not track my hours or my “actual” time on tasks

Scrum considers tracking the time individuals spend on individual tasks to be wasteful effort.  Scrum is only concerned about time when it comes to the time boxes of the Sprint and Sprint meetings.  Scrum also supports sustainable development, which implies working sustainable hours.  When it comes to the completion of tasks, the team is committed to delivering value.  The tasks in the Sprint Backlog represent the remaining tasks that the team has identified for delivering on its committed increment of potentially shippable value for the current Sprint.  The tasks themselves have no value and therefore should not be tracked.  Scrum is only concerned about burning down to value delivered.  Time spent on individual tasks is irrelevant.  What if I track my hours or my “actual” time on tasks?  This promotes a culture of “bums in seats” – that it is more important for people to be busy at any cost instead of getting valuable, high-quality results.  This also promotes bad habits such as forcing work into billable hours even though it is not.  Overall, time tracking in a Scrum environment does much harm and can undermine the entire framework.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: No member of my team reports to me

Inside the Scrum Team, including the Product Owner and the ScrumMaster, no individual should report to any other individual.  The team reporting structure should be flat.  This does not necessarily mean that all Team Members are peers in the org chart.  For example, one team member could be quite senior, and another quite junior.  However, for the Scrum principle of self-organization to work effectively, individual Team Members should have no concern about what their “boss” wants them to do.  Instead, within the Scrum Team, there should be a completely safe environment for individuals to volunteer for tasks, raise obstacles, provide candid feedback to any other Team Member, and have a mutual sense of commitment to the work of the team.  If the Scrum Team is absent of reporting relationships then it has a much higher chance of becoming a high-performance team.  If there are reporting relationships within the Scrum Team there are often significant obstacles to full openness and self-organization and this, in turn, will significantly hamper the performance of the team.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail