Rand Eaton 11/2/16 Rand Eaton 11/2/16

What is a Product Backlog Item?

Hi! Dee Rhoda here from Collaborative Leadership Team. I'd like to check in with you about a question. What is a Product Backlog Item? Or as I'd like to call it PBI.

This is not to be confused with the PBL. We all know that the PBL is - the peanut butter and liverwurst sandwich we enjoy for lunch every day. But really, the PBL is the Product Backlog and that is where you find the ordered list of Product Backlog Items, PBI's.

PBI's are simply work that needs to be completed for a product or a service in order to provide business value. For example, specifications, requirements, enhancements, fixes and user stories are all considered Product Backlog Items. Who can create a product backlog item? Anyone! A Product Owner, a Team Member, a Business partner or a Stakeholder can add items to the backlog at any time.

For example, the team may add any additional work that they discovere during planning or sprinting. The customer may add requests for enhancements. The end user may see a need for a bug fix. The Product Owner can add their work too. They may need to add work for getting communication or training materials created.

The key is to have good PBIs and to make sure that the Product Owner is aware of them because the Product Owner owns the backlog and they are ultimately responsible for the success of the product or the service.

So, what makes a good PBI? Well, here I'm going to refer to Bill Wake's INVEST concept as a starting point. A PBI should be Independent, Negotiable, Valuable, Estimable, Small and Testable. Even though the INVEST concept is a good one, don't forget the most important action that comes from a PBI is the conversation that it generates between the business and the development team. That's agile principle #4 - Business people and developers must work together daily throughout the project.

Ultimately, what is a Product Backlog Item? It's a reminder to have a conversation about what and in what order to work to deliver the most value to our end users and to our customers.

If you're interested in learning more about the product owner role, please visit us at our website collaborativeleadershipteam.com

Rand Eaton 5/30/16 Rand Eaton 5/30/16

Want a better definition of done? Do a load of laundry!

Collaborative Leadership Team’s Dean Gabbert, Certified ScrumMaster and Certified Scrum Product Owner, shares what he has learned about Scrum’s Definition of Done from the simple task of doing laundry.

My favorite example to use in teaching or coaching the importance of a good Definition of Done is to say, “Imagine having a conversation with someone you love most in the world about what it means to be done when doing the laundry.” This is usually met with a lot of eye rolling; laughing and inevitably someone proudly stating their definition of done: “All clothes washed, dried, folded and put away.” Someone else adds “Letting someone else do it”. I share that my two boys’ definition of done is throwing their dirty – and sometimes clean – clothes down the laundry chute and feeling so proud because they are “helping.”

Regardless of what your definition of done is for laundry, it is a great way to think about, and more importantly talk about, what it means to be done with Product Backlog Items (PBIs). Is it always the same? Do the clothes need to be washed, dried, folded, socks paired and everything put away in a drawer or closet by the end of every Sprint? Or would it be considered “done” if you just threw a load of clothes in the washing machine and walked away? Technically they are “clean” at the end of the cycle right? Is there something that you are currently doing that could be outsourced – to the dry cleaner? Is it possible to combine light and dark clothes? I know some of you out there just gasped in horror. But could these be washed in cold water, speeding things up a bit to achieved clean and dry?

Are their certain PBIs that need more attention than others? Like putting an item in one of those meshed bags and sending it through on the delicate cycle and drying on a clothes line. Does this add time and a bit of uncertainty because drying is not controlled? Is there something in your Product Backlog that needs to be pre-treated, get an extra soak and put through on the Ultra-Clean cycle because it’s so dirty and smelly? Then you might even ask if it is even worth cleaning or would you be better off throwing it away and buying something new?

I can’t guarantee that this will help find that missing sock. But it will help Product Owners and Development Team members have a good conversation about what done looks like.

Want to learn more? Join Dean’s upcoming Intro to Agile course here: http://tinyurl.com/h7wlvnw

Embed Block

Enter a valid embed URL or code.

Rand Eaton 5/29/16 Rand Eaton 5/29/16

Agile Coaching Sense and Sensibility...

Not so long ago, I was having a conversation with a colleague about an Agile team that I was coaching. I was describing my observations and thoughts about the team’s dynamic and why this was causing stress for them. I then asked my colleague, “Does that make sense?”. I had hoped for insight, inspiration or a “coach the coach” moment. The response I got was not what I expected. I received a 10-minute soliloquy on the difference between the questions, “Does that make sense?” vs. “Do you understand?”

Collaborative Leadership Team’s Dee Rhoda, Certified Scrum Professional, shares her perspectives on asking “does this make sense”?

Have you ever been in a conversation with someone, described a situation or made a statement and then asked; “Does that make sense?”

At first I was put off by this nonsense answer. What is so important about the two different questions and how was this distinction going to help the team? Honestly, it took me months to get past my annoyance. But as I sat down to write this blog – with the intention of lampooning the need for distinction – I realized, there is an important difference for coaches between those two questions.

You may understand what the speaker is saying. However, is what the speaker is saying making sense to you? When someone points to the sky and says; “What a beautiful shade of green”. You understand that the person sees a green sky but, does that make sense to you? In order to have the person’s statement make sense to you, you need to continue the conversation. Ask more questions and take in the contextual environment to help you understand and be able to effectively coach.

Coaches are challenged on a regular basis with ensuring their clients that they understand and authentically empathize. Of course, language plays a key role in reinsuring the client that they are being heard. Therefore, the point is not necessarily proper grammar use or debating semantics. It is that the coach is present with the client. Hearing them, understanding them and helping everyone make sense of what is going on – and what is not going on.

When I am coaching, I have started using a technique introduced to me through Lyssa Adkins called level two listening. It’s a style of listening where the coach does NOT say: “I hear you. I have some things to add about what you just said”. Instead they say “I hear you. I accept you. Hmmm…. I’m curious about what you just said.” In this way, the coach accepts what the person is saying to them and the words the person chooses to use. (2016 Agile Coaching Institute). I want to hear the person and know their perspectives. In this way, I can understand and make sense of the information the person is giving me.

The next time you are asked, “does that make sense?” stop and think. Does it? If the answer is no, tell them so. Then ask; “Help me to understand so that it does make sense to me.” Maybe the sky was a beautiful shade of green because the person who stated this is color blind and this is how it appears to them. You won’t know until you take the time to listen and understand.

Rand Eaton 5/28/16 Rand Eaton 5/28/16

Agile Leadership…It’s about the Flow

One question Christian Antoine, Scrum Trainer and Coach, frequently hears from leadership as an organization begins their Agile journey is “Does Agile or Scrum require an organization restructure?”

No Agile framework prescribes if organizations should be structured or not. In striving for agility, most companies state their goal as beating the competition in speed to market or to retain their foothold in that market. Organizational agility means consistently responding to those market forces and gaining desired outcomes in complex environments. Agile organizations can “turn on a dime, for a dime” because they are able to process information faster.

Consider the following in your organization:

How fast does information flow through the organization?
Is the information unfiltered? Accurate?
How long does it take your organization to process new information?
How fast can your organization respond to new information and gain the desired outcome?

Any entity (individual or organization) that is able to flow information in response to an event and process it the fastest wins. This is similar to a pilot’s decision cycle of Observe, Orient, Decide and Act developed by military strategist and U.S. Air Force Colonel John Boyd. The pilot who goes through the OODA Loop in the shortest time prevails in air-to-air combat because their opponent is caught responding to situations that have already changed.

Colonel Boyd was dubbed “Forty Second Boyd” for his standing bet that he could defeat any opposing pilot in air combat maneuvering in less than 40 seconds beginning from a position of disadvantage. Boyd breaks down the cycle into the four, interrelated and overlapping processes to be cycled through continuously:

Observation: the collection of data by means of the senses
Orientation: the analysis and synthesis of data to form one’s current mental perspective
Decision: the determination of a course of action based on one’s current mental perspective
Action: the physical playing-out of decisions

Boyd emphasized that this decision cycle is the central mechanism enabling adaptation (apart from natural selection) and is critical to survival. Sounds familiar when we consider Scrum’s Transparency, Inspect and Adapt doesn’t it?

If your organization’s hierarchy or structure impedes the ‘flow of information’, this will be exposed by adopting any Agile approach. If restructuring will speed up the flow of information, it may be something for leadership to consider but it is not necessarily required.

Want to learn more? Join Christian’s upcoming Certified Scrum Master course here: http://tinyurl.com/h7wlvnw

Rand Eaton 5/27/16 Rand Eaton 5/27/16

Step Up Step Back or Step Out

Collaborative Leadership Team’s Angela Johnson, Certified Scrum Trainer, shares perspective in this post about Stepping Up, Stepping Back or Stepping Out. A big miss in choosing to adopt Scrum as the new way to do work is just that: it’s a new way to do work. In other words, there is still work to do.

Collaborative Leadership Team’s Angela Johnson, Certified Scrum Trainer, shares perspective in this post about Stepping Up, Stepping Back or Stepping Out.

A big miss in choosing to adopt Scrum as the new way to do work is just that: it’s a new way to do work. In other words, there is still work to do. It’s a choice to use Scrum to do that work. It’s a different choice to use another framework to do the work.

Inevitably, people wonder what happens to their traditional “role” or the way they used to do work. There is job security – but not role security. There is plenty of work to do. But the roles are completely different in Scrum than other ways of doing work.

Yet other organizations think that Scrum means adding people to “fill” the new roles in addition to their existing roles. And others think that Scrum means doing the work with fewer people which creates fear about job loss.

All of these myths indicate a lack of understanding about Scrum. Scrum does not seek to tell any organization to add people or to remove people. It’s just a different way to work – if the organization and the people in it – choose to use Scrum.

CLT’s working agreements include Step Up or Step Back. If someone is passionate and wants to use their time and talents to champion an idea, they are empowered to go for it. Yet others may be happy to provide feedback or take a more passive role in a particular endeavor and that’s ok.

In sharing Step Up or Step Back as one example of a working agreement in a recent Certified Scrum Master (CSM) discussion someone said “And please add, or Step Out.”

We spent some time exploring this idea. Some in class mentioned that since they began using Scrum, it was evident that they have people who are not interested in this way of doing work. Does that mean they have to leave the organization?

At a minimum Scrum defines three roles but there will be other roles in any organization. Yes, the roles will change. If anyone is uncomfortable about this, be it the identified Product Owner, the identified ScrumMaster or any member of the identified product Development Team, there may be a need to Step Up, Step Back or to Step Out:

Stepping Up: contribute, help change, grow and evolve the product, the team and the company

Stepping Back: observe, offer feedback and identify potential gaps

Stepping Out: find a place to add value someplace in the company or find a place to add value outside of the company.

Stepping Out does not always have to mean leaving the organization. It can mean finding another place inside the organization – another team, another department – to better define yourself, your aspirations and leverage your talents. In nearly every situation we all have 3 choices: to step up, to step back or to step out.

Want to learn more about how a Scrum Master can facilitate creating working agreements? Join us for our next Certified ScrumMaster® course: http://tinyurl.com/j7qqdnb