Most of us have to pay a visit to the scissor man/lady every couple of months. Others who don’t have to or choose not to, I envy you. As a kid, my visits to the barber shop were scary ritual. The thought of someone using scissors, clippers and other sharp pointed tools a few millimeters from my scalp and ears was terrifying. After surviving many close calls with sharp objects I was fairly certain that the worst that could happen would be a couple of cuts, minor scrapes and a hideous hair style. Over the years what gave me courage to go to our neighborhood barber shop was our barber’s technique/skill and relaxed friendly conversation that always ensued at his place. (That and my mom and lately my wife :).

I have not completely overcome my fear of visiting barbershops yet. There is always the possibility of getting bruised or a bad haircut. However I find it reassuring that it is in the nature of my fur to grow back and warrant another shot at presentable appearance.  Scrum teams & PO’s that appreciate this emergent characteristic of product backlog find themselves engaging in healthy dialogue during backlog grooming sessions . As a coach, helping product owner & team to groom their backlog I seek to use tools and techniques that foster collaboration, allowing them to acknowledge the emergent nature of product backlog items. I have often found myself playing the role of that friendly neighborhood barber, armed and ready with agile tools to help product owners and teams groom their product backlog.

Collection of techniques

1. User Story format: (As a [type of user] I want [some goal] so that [some reason])
2. Three C’s (Card, Conversation and Confirmation)
3. INVEST model
4. Special story types - Research, Spike & Tracer bullet

Collection of Tools

1. Index cards or Sticky Pads (lots of them)
2. Sticky dots
3. Sharpies
4. Poker Planning cards
5. Whiteboard/Flipcharts.
6. Scissors

These are some tools & techniques that I find myself applying most frequently. The list above is a basic toolkit. (Good barbers always have a secret stash of innovative experimental contraptions, should the customer feel adventurous

Application of tools and techniques during product backlog grooming is highly contextual and it largely depends on the nature of product backlog prior to grooming session, comfort level of product owner and team with grooming techniques and other external factors that indirectly influence the backlog grooming session.

A well functioning agile team grooms its product backlog, at least once, every sprint to build a professional product that sports stylish curls with hints of highlighting.

When I started back in July, I was not sure Why? - I wanted to blog. After this hiatus I believe I have come to terms with my purpose behind this effort.

My intention with this blog is to journal my activities and thoughts as an agile coach. I hope others benefit from it.  Most important for me is to be able to look back at my writings in a future date and reflect at how I have evolved over a period of time. For the last couple of years I captured similar artifacts (notes, pictures, learnings) in physical notebooks, word docs and various other formats which to a large extent are beyond recognition. The thought that my posts may possibly be read by other people forces me to strive for clarity & helps me to be a better communicator. I believe that if at least one other person understands my posts then there is a better chance that I, in future, will understand it myself.

I have now abandoned my quest to be a prolific blogger. I am now comfortable with the notion that my posts will be far and between - there I said it! I hope to make them good enough for the future me

During the course of this retrospective, team members discussed how they can improve trust, respect & communication within the team. The fact that the team had individuals from different cultural background was not missed. The crowning moment during the retrospective came when one of the team members said:

“In my culture, we have to be friends, for me to do good work. In the western culture, I have to do good work, for us to be friends.”

These words have echoed in my head for a very long time. His insight has been a great learning experience for me. I have learned to acknowledge and appreciate differences in individual values. But what are these values?

Exercise: Sharing Values

Step I: Identify a pair (optional)

Ask your team members to identify someone within the team that they are comfortable with. Ensure all pairs have been identified and if there are odd numbers of people, the facilitator can pair with the lone individual. Ensure that every one has some index cards and a sharpie.

Step II: I don’t like it …

On a single index card, ask each team member to complete this statement:

“I don’t like it when someone/people …… “

Encourage each team member to write down 2-5 such statements on separate index cards.

I have found that it is easier for us to identify behaviors that we don’t like, especially when we have been at the receiving end.

Step III: Exchange Cards

After everyone is done writing, exchange all your cards with your partner.

Variation: If you have opted not to do Step I, then place all these cards in the basket/hat. Now randomly pick cards from the Basket/Hat. If you get a card that is yours, then place it back into the bucket/hat. Ensure all cards have been distributed.

Step IV: I like it …

On the back of each index card, write down a statement that will counter your partners “I don’t like it …” statement with

“I like it when someone/people….”

You will be amazed how your team member’s insight into your hot-button issue helps you recognize behavior that you will truly appreciate!

Step V: Share Values

Go around the table where each team member reads aloud a statement that begins with “I like it when …”. Take turns reading one statement per team member at a time until all statements are exhausted.

These are your team’s value statements. These statements provide a simple list of positive behaviors that are currently valued in your team.

Caution: As a facilitator/scrummaster refrain from vocalizing these statements yourself. I believe it is very important for everyone in the team to hear these positive behavioral statements from their peers.

Step VI: Team Values Chart

On a Big Visible Chart only capture statements, that begin with “I like it when …”. Radiate this information in your team area for the benefit of your team members and others who interact with your team.

This exercise takes less than 30 minutes to do. Try this exercise again after a couple of months; see how far your team’s values have evolved. As a manager/scrummaster/team member, if you feel tempted to dictate good behaviors to your team, take a deep breath and try this exercise with them. Maybe, just maybe, your team will self-organize to correct its own behavior.

ps: Suggest destroying index cards that were used for this exercise.

• DoD is a collection of valuable deliverables required to produce software.

Deliverable that add verifiable/demonstrable addition of value to the product are part of the definition of done. Such as writing code, coding comments, unit testing, integration testing, release notes, design documents etc. Definition of done helps frame our thinking to identify deliverable that a team has to complete in order to build software. Focusing on value added steps allows the team to eliminate wasteful activities that complicate software development efforts. It is a simple list of valuable deliverable.

• DoD is the primary reporting mechanism for team members.

My favorite agile manifesto value is “Individuals and interactions over processes and tools”. Would it not be effective reporting to say, “Feature’s done”? DoD is a simple artifact that adds clarity to “Feature’s done” statement.  A feature or Product Backlog Item is either done or it is not-done. Using DoD as a reference for this conversation a team member can effectively update other team members and product owner. Kindly note that by primary reporting mechanism I do not intend that DoD is the only reporting mechanism used.

• DoD is informed by reality.

Scrum framework sets a very high bar of delivering “Potentially Shippable Software” at the end of every sprint. To me, potentially shippable software is a feature(s) waiting on product owner’s discretion to be released to end-users. Teams that are able to release to end-users within a maximum of 2 days can be reasonably said to have their product in potentially shippable state. For such teams: Potentially Shippable = Definition of Done.

For other teams working to achieve potentially shippable state, their DoD contains only a subset of deliverable necessary to release to end users. Such teams have DoD at various levels:

§   Definition of Done for a Feature (Story or Product Backlog Item)

§   Definition of Done for a Sprint (Collection of features developed within a sprint)

§   Definition of Done for a Release (Potentially shippable state)

There are various factors which influence whether a given activity belongs in DoD for a feature or for a sprint or for a release.

The most important is for the team to realistically answer:

Can we do this activity for each feature? If not, then

Can we do this activity for each sprint? If not, then

We have to do this activity for our release!

For activities that cannot be included for a sprint/feature: “Discuss all of the obstacles which stop them from delivering this each iteration/sprint” - (Building a Definition of Done)

Some of the common root causes for impediments that I have observed:

a.   Team does not have the skill set to incorporate activities into the definition of done for a sprint or for a feature.

b.   Team does not have the right set of tools. (Example: continuous integration environment, automated build, servers etc.)

c.   Team members are executing their sprint in mini-waterfalls. Aha! Opportunity to be more cross-functional. Sharing of responsibilities across functional silos.

• DoD is not static

DoD changes over time.  Organization support and team’s ability, to remove impediments, enables inclusion of activities into DoD for feature/sprint.

• DoD is an auditable checklist.

Task break down for a feature/story happens during sprint planning and also within a sprint. DoD is used to validate whether all major tasks are accounted (hours remaining) for. Also, after a feature or after a sprint, is done, DoD is used as a checklist to verify whether all necessary value added activities were completed. It is important to note that the generic nature of the definition of done has some limitations. Not all value added activities will be applicable to each feature since the definition of done is intended to be a comprehensive checklist. The team has to consciously decide about applicability of value added activities for each feature. For example following user experience guidelines for a feature that provides integration point (eg: web service) to another system is not applicable to that particular feature, however for other features within the system that interface with a human being require user experience guidelines to be followed.

Summary:

Definition of done is orthogonal to user acceptance criteria (functional acceptance) for a feature. It is a comprehensive collection of necessary value added deliverables that assert the quality of a feature and not the functionality of that feature. Definition of done is informed by reality where it captures activities that can be realistically committed by the team to be completed at each level (feature, sprint, release).