Blog


How to Build and Motivate Your Scrum Team: Part 1

“Understand their past so that you can better guide them toward their future.”

As an agile coach or Scrum Master, at one time or another, we have all faced the situation of introducing Scrum to a new team or turning around a Scrum team that has lost its way. I feel that the old saying about Scrum that “the concept is simple, it’s the execution that is hard” is referring to those two situations.

In either situation, the first thing you need to do is start from or go back to the beginning and treat these teams as if they were a new group of people.

You need to keep in mind that most core team members either come from:

A Waterfall environment where they were subjected to unrealistic deadlines, long work hours and their expert opinion ignored or never fully leveraged An agile environment that was agile in name only where the product owner and Scrum Master operated with Waterfall’s mentality, and the benefits that come from working on real a Scrum team were never realized.

Thus, calling a group of people a team, even if they have worked together before, does not necessarily make them a team. A team is composed of members that know through experience the value and the level of commitment that each team member brings to the team. This is something that does not happen overnight. It’s a journey that you and the team take together.

As an agile coach or Scrum Master, you need to connect with your team on a logical and emotional level. The logical level stems from your knowledge of Scrum and how well you transfer that knowledge to your team. The emotional level stems from the trust you build with the team and within the team as you guide them through the adoption of the Scrum framework and they come realize its benefits.

The First Step

The first step in the journey is level-setting the team through training. To make the logical connection, I want them to know what I know.

As part of my own continuing improvement, I’ve put together training slide decks for the Scrum Master, the product owner and the core team roles, which I use to ensure that they gain that all-important shared understanding of the Scrum roles and associated responsibilities.

I also find these training decks to be useful for bringing new members up to speed when changes occur within the team, and I continue to update them as I encounter new and better ways to express ideas.

The Second Step

The second step is to help them to decide what kind of team they really want to become and is where I lay the groundwork for building a team and starting to make the emotional connection. So, it is here that I ask them to tell me their thoughts on what makes a great team.

For this exercise, I have them write one thought per Post-It note and when finished, put them on the board. I often use Post-It notes to ensure full participation, especially from the less-vocal members in the group.

Once complete, we rack and stack the notes into three to five categories. Based on the number of categories, each member receives the same number of votes and is asked to go up to the board and select those thoughts on the board they feel are the most important characteristics of great team.

After the votes are tallied, we take the winning thoughts and turn them into value statements that are positive and mean same thing to everyone in the group.

The following is a sample of some actual team value statements:

Sharing knowledge and information freely and openly among team members. Putting the team first and the willingness to do any task necessary to reach each sprint goal. Asking for help when you need it and without delay, and helping others when they need help or when you find yourself with spare time. Taking the time to listen, understand and respect your teammates’ opinions and views.

I have been in many team spaces over the years where I’ve seen team values expressed using single words such as “responsibility,” “commitment,” “trust,” “respect,” etc. and find it sadly lacking because if I don’t know what the word “respect” means to the team, how can one expect those team members to know?

And if that is indeed the case, does this team really know what kind of team they really want to become?

However, when you look at the team value statements mentioned above, there is no question about what that team thinks it takes to be a great team. I would also like point out that value team statements are not a one-time exercise where you are done after you print it out and post it in the team’s space.

This is a tool you will use from time to time in your retrospectives where you might ask the team, “Did we as team live up to a specific team value during this sprint?” … or to remind them what kind of team they want to become. You might also add or adjust a team value statement as the result of what the team learned during a sprint.

The Third Step

The third step is to have this group of people come together to decide how they want to organize their workday. This is what I call a “team agreement,” an example of which is shown below.

Business Hours: 9:30 a.m. – 3:30 p.m. Daily Standup: 9:40 a.m. – 9:55 a.m. Coding Hours: 1 p.m. – 5 p.m. Mid-Sprint Check: Sprint Day 5

Business hours is the timeframe that the team agrees everyone should be on the premises. The daily standup time is when the team agrees to meet and plan their work for the day. Core hours are generally used for the team to engage with others. Coding hours is a period where the team is not to be disturbed so they can focus on work.

And, the mid-sprint check is the point in the sprint cycle where the team reviews the task board to determine if they are still on track to complete all the stories, and if not, how to adjust their work strategy to get back on track.

Conclusion

With this process, we take into consideration the group’s past project experience and focus on laying down a foundation for shaping this group of people into a team.

We start off making a logical connection by explaining the Scrum framework roles and responsibilities for every person in the group so that they now know what the job entails. We then engage them to tell us what they think makes a great team.

We ask them what is most important to each of them, and then assist them in creating their value statements, thereby making that first emotional connection. In the last step, we take our first opportunity to empower them by asking to self-organize their workday.

In Part 2 of this article, we will continue the journey and discuss how we further build on this foundation we laid out in Part 1 as we guide a team through the adoption of the Scrum framework. 

5 Signs Your Team is Lacking the Agile Mindset

When a Scrum Master joins a new team—whether it’s a team new to Scrum or one that has been practicing Scrum for a while—he faces different challenges. Therefore, the duties and focus of the Scrum Master for the first days are different in both cases.

In the first case, where the team is new to Scrum, most of his time and focus is used to teach and coach the team through Scrum. There is often a standard approach to how the team will be introduced to agile then Scrum.

On the other hand, when he joins a team with only some Scrum experience, he needs to act differently. For example, he needs to watch and observe more how the team is acting and how the members are interacting together to see if the agile mindset exists.

Some teams think they are agile by holding the prescribed meetings, but this is not the essence of agile. This type of team needs to be coached to cultivate the agile mindset, regardless of which framework is in practice.

There are many signs that indicate the lack of an agile mindset. Let’s look at some of the common signs that should send a warning signal to the Scrum Master that the team needs to refresh its Scrum and agile knowledge.

1. Knowledge Silos

One of the teams I worked with in the past used to have each developer working on a specific part of the product, and only he knew about it. Whenever a problem happened, they needed to wait for him to fix it.

This can also manifest when certain persons are pre-assigned to specific tasks or user stories during the sprint planning. This behavior prevents the team from working on priorities; rather, each person would work on the part he/she knows without considering the deliverability at the end of the sprint.

Another drawback of such behavior is the lack of team spirit and teamwork, since each one will be working on his/her own island without caring about what happens on the other island.

2. Not Working on Top-Priority User Stories

Teams working on a user story at the bottom or in the middle of the sprint backlog miss the concept of prioritization, and it could also signify a conflict with the product owner or a product owner who is not doing his homework.

Having a prioritized sprint backlog, and of course, a product backlog, is a product owner’s main responsibility to maximize the value delivered each sprint. If a team decides to work on a user story at the bottom, it is either the user stories that are not properly prioritized, or the team needs to understand the importance of picking work based on priority.

3. Separate User Stories for Testing

Having separate user stories only for testing of other user stories, whether these user stories are in the current sprint or a previous one, signifies that the team either doesn’t have a definition of done (DoD) or they don’t understand the meaning of deliverability.

Although it is acceptable to have separate user stories for developing automation tests, it’s a big red flag when you have user stories for “testing” only. In this case, the team needs to be coached to understand what it means to deliver a working product increment at the end of the sprint and to define their Definition of Done.

Without verifying your implementation, you can’t make sure that you are delivering a working software.

4. No Visibility of the Burndown Chart

If the team doesn’t have or doesn’t use the sprint burndown chart, their progress won’t be clear to them. The burndown chart is a tool to show very easily and quickly how focused the team is. The team might feel they are doing a lot of work, but yet they have flat burndown. This means they are not delivering, and they need to regain their focus to deliver more often.

Another misunderstanding that I have experienced with some of the teams is when they ask to have their burndown chart burnt based on tasks finished rather than user stories.

I consider this a bad practice, since it gives them an illusion of achievement, and at the end of the sprint, you might be surprised by having so many tasks finished but not delivered because the whole scope of the user story, including testing it, was not finished.

5. They Estimate Only for the Upcoming Sprint

Although it is one of the basics of agile to a have prioritized, estimated backlog, some teams might estimate only the scope of the upcoming sprint during backlog grooming sessions. Some teams don’t even have these sessions.

Planning only per sprint is dangerous since it doesn’t allow the product owner to anticipate or plan when certain features will be released. In these cases, the Scrum Master will need to teach the team the several levels of agile planning, and the value of having a prioritized estimated backlog for the team and the customer.

These are just some of the signs I have experienced when joining a team that let me know that the team doesn’t yet have an agile mindset, and more education should be the focus. Have you seen signs like this when you’ve joined a team? Do they exist in your current teams?

I would love to get your feedback in the comments below.

Is ‘Meeting’ Really a Dirty Word?

Just the other day at stand-up, I heard a dev team member say: “Yesterday I didn’t get anything done. I had a day of meetings.” As the team’s coach, I said nothing at the scrum, but took the opportunity afterwards to ask a question of the team: “Have you heard of ‘The Law of Two Feet’?”

I received many questioning glances. So I elaborated:

If you see a meeting as an opportunity to connect, learn, educate, share, collaborate and/or inspire, then by all means, use your two feet to join it. On the other hand, if you find no value in a meeting (proposed or in progress), be polite and see if you can get things on a better track. If not, use your two feet and walk away. (Feel free to steal a line my friend Jay Hrcsko uses: “Excuse me. I have to return some videotapes.”)

I don’t read the minds of my teammates, but I’m pretty sure at least a few folks thought that I had finally gone off the deep end. “Don’t show up or (gasp) walk out of a meeting that an SVP called?!”

They’d rather sit there, multitasking, pretending to be engaged? Maybe I need to print up some get-out-of-jail-meeting-free cards.

Only Two Kinds of Meetings

Let’s cut to the chase: there are only two kinds of meetings: good meetings and bad meetings. That’s it. Nothing really in between. Sure, we could start to subdivide the good meetings into types: alignment, creation, one-on-ones, etc. But let’s stick with big buckets.

Good Meetings

There’s a simple formula to evaluate if what you’ve been invited to / are attending is a good meeting. It’s a formula that I learned from Lyssa Adkins: Good Meetings = P+O+W+E+R

Purpose: Is there a clear, anticipated purpose to this meeting? For example, make decisions, solve problems, exchange ideas and information. Do we plan to discuss the “right stuff”? Is there a selective agenda? (An upfront purpose doesn’t rule out the possibility of some good improv….) Outcome: Are we all clear on what we expect to gain, produce, decide, solve or get as a result of this meeting? WIIFM: Do I know what’s in it for me? Will I gain value? Will I provide value? Am I interested in the items on the agenda? Will this empower me and / or my team? In his book, “The Agile Team Facilitator,” Martin Alaimo breaks the WIIFM variable of the formula into two parts: recognition and attraction. These tell each invitee why their participation is important, and explains the benefits they can obtain by showing up. Expectations: Are things like start time and end time clearly communicated? What kind of preparation is needed? Is there sufficient time to prepare? Is everyone clear on the decision-making process (e.g., majority vote, full consensus, consensus minus one, unanimity, etc. See Decision Making Patterns for Teams)? Are there clearly communicated expectations about listening? How about actually showing up? If you aren’t in a culture where all meetings are optional, clarify things. Roles: Will everyone who needs to be there actually be there? Who’s facilitating the meeting (some folks call this role the referee)? Who’s leading which topic on the agenda? Who’s taking notes? Who’s the timekeeper? Who owns each action item produced? (Another sign of a good meeting is that we don’t have to have it a second time.) Bad Meetings

There’s an even simpler formula to tell if you’ve got a bad meeting arising: 

Ask, “Can what this meeting is attempting to accomplish be done any other way?”

If the answer is “yes” – you’ve got a bad meeting. Or as VM Brassuer defined it many years ago: Selfish, Haphazard, Informational and Tardy. Which has a nice acronym to it. Those are the meetings you don’t want to step into.

First: Consider Asynchronous Communication

Before you go ahead and schedule that next meeting simply out of habit, pause and figure out its purpose. You might start by roughing out an agenda. When you have that, ask yourself: Is there another way we can address these items beside having a meeting? For example, would some other communication method like chat, email, wiki, etc. work just as well, if not better?

The advantage of async communication methods over a scheduled interruption – whoops, a meeting – is that the “conversation” can easily be quarantined. Someone who doesn’t mind being interrupted can monitor these channels and respond – if they choose – in near real time.

Someone who is in the zone can minimize their Slack/HipChat/email window, turn on DND and respond at their leisure. (See Disturb / Do Not Disturb.) 

A word of advice: when you go async, make sure your communication style is actionable. Don’t rush things. After all, you’ve got extra time now that you don’t have to go to a meeting. Use it well. (See Slowing Down to Speed Up – Effective Asynchronous Communication.) 

When You’ve Ruled out the Impossible... Have a Meeting

It seems to me that Sutherland and Schwaber must have had an aversion to meetings. They avoided the word completely back in 1995 when they codified Scrum. The framework has a number of prescribed events that to the uneducated observer look a lot like dreaded “meetings.”

These events or ceremonies really are accomplished best via synchronous communication and discussion: retrospectives / post-mortems, 1-1 reviews, sprint planning, kick-offs, backlog estimating, demos. Add in monthly and quarterly strategic planning sessions and yep, we’ve got ourselves some meeting time.

So why don’t we make the best of use of that time and, like any good agilist, inspect and adapt how we are using it?

Feedback Loops

Find out how your meeting went by using a retro technique from Growing Agile. Reserve the last two to five minutes and ask the participants:

Was this meeting valuable? Why or why not? Did you pay attention all the time? Why or why not? Did everyone else pay attention all the time? Why or why not? Which parts felt great? Why? Which parts felt awkward or odd? Why?

 If you don’t yet have sufficient psychological safety so that people will vocalize their thoughts, hand out sticky notes instead. Ask people to populate a feedback wall, right next to the exit door.

The Value of Synchronous Communication

I don’t know about you, but I haven’t yet found a way to get rid of meetings completely. And I’m not sure that should be the goal, although I heard someone say that was their definition of a successful agile transformation: No meetings!

Cut meeting time in half, and then half again? Yeah, I can do that. I’ve made it a point to schedule short meetings. If I think we need 30 minutes, I’ll schedule 20. An hour? I’ll book 50 minutes. But get total meeting time to zero? Unlikely.

Planned, as well as ad-hoc synchronous, communication, aka meetings, reduce the potential for misunderstanding (provided folks say what they mean and mean what they say). Good meetings provide the opportunity to come up with meaningful solutions to difficult problems, to collaborate, to get to a point of common understanding efficiently – more so than 20 back and forth Slack, JIRA or GitHub comments.

Good meetings help make sure teams don’t just “get stuff done” but that they get the right stuff done at the right time. Your time is a limited resource, use it, along with your two feet, wisely.

Beyond Sprints: How XP Can Work for Modern Teams

Search “agile scrum” in the books section of Amazon, and you’re likely to find around 835 results. Search “agile extreme programming” and you’ll get just around 120 results back.

While this exercise might not be a scientific measure, it does reflect the dominant mindshare of agile discourse that Scrum has grown to achieve over the years. Indeed, just one look at the website of Scrum Alliance, and you’ll find six certifications specifically for Scrum, hundreds of Scrum training courses held around the world, corporate sponsorships, and essentially an entire commercial ecosystem ‒ none of which exist for Extreme Programming.

I have nothing against Scrum ‒ I went through Certified Scrum Product Owner training and found it immensely helpful. However, I don’t think Scrum should be where the discussion ends and I think other methodologies are far too often overlooked in agile discussions.

In fact, I’ve found that many of my well-meaning colleagues often start describing agile with terms like “sprints,” “estimates,” and “backlog grooming” ‒ but in reality, they’re usually describing Scrum rather than agile.

While Extreme Programming (XP) might not be for every team, I believe that every team should at least know what it is. Indeed, respected Scrum trainer and Scrum Alliance founding member Mike Cohn even wrote, “My typical advice to teams is ‘start with Scrum and then invent your own version of XP.’”

What is Extreme Programming?

Like all forms of agile, Extreme Programming emphasizes frequent releases and short development cycles to adapt to changing requirements and improve productivity. However, XP does not prescribe strict sprints, estimates, nor Scrum Masters.

In true agile fashion, XP posits that changes are natural, unavoidable and even desired when developing a software product.

Unlike Scrum, XP extends agile by emphasizing four key programming activities.

The first of these engineering practices emphasized is coding. Emphasis of coding is a stipulation that code is the most important aspect of software, and without it, no product would exist.

Coding is also seen as a fundamental tool in many working functions, such as using coding to find optimal solutions, and explaining concepts and solutions to others.

Unit tests and acceptance tests (testing), listening to customer needs and seeking frequent customer feedback (listening), and designing logic into the system to prevent an overabundance of dependencies and logic issues (designing) round out the other three programming activities that XP emphasizes.

Similar to Scrum, XP also has its own set of values: communication, simplicity, feedback, courage and respect. These values all reflect core values of the Agile Manifesto, emphasizing the people and interactions needed to get working software built, as well as maintaining constant customer collaboration and responding to change.

What Are the Advantages of Extreme Programming?

In my own personal opinion, I find XP to be less prescriptive in practice than Scrum. I think far too many professionals latch onto a framework like Scrum and begin mandating it in the most rigid way possible, which runs the risk of being contrary to the Agile Manifesto by overemphasizing processes, tools and plans.

While many teams stand to benefit from the more elaborate framework and processes offered by Scrum, more nimble and self-disciplined teams are able to thrive with less procedural overhead.

Indeed, many teams are even reminding us that processes like estimates are not necessarily a must-have, and may even be counterproductive at times. Many people are shocked when I remind them that estimates aren’t actually a universal aspect of agile, nor specifically prescribed in popular methodologies like Kanban or Lean.

In addition to being liberating and removing processes which can slow teams down, I believe that XP is more adaptive to change than Scrum, as it usually allows changes within planned iterations.

I’ve seen far too many Scrum teams get locked into the idea of following two-week cycles as a default, whereas XP seems more compatible with modern practices like shipping code and features multiple times a day.

This isn’t to say that XP is all about throwing all process to the wayside. On the contrary, I believe the emphasis on practical engineering activities like testing and pair programming helps keep teams focused on processes that have a much clearer impact on actual work quality, rather than business planning measures like estimates and sprint velocity, which tend to feel more indirect and distracting from getting the actual work done.

Finally, I personally like the fact that XP emphasizes frequent communication with the customer. By frequently talking to the customer, the team building the software can uncover misunderstandings or changes in requirements and address them more rapidly, rather than adopting the mindset that they’ll wait to present their work to the customer at the end of a sprint.

Can Extreme Programming Really Work?

Extreme Programming isn’t for every team, but it could be. With Continuous Delivery and streamlining of deployment becoming more and more common, I believe that Extreme Programming is a very appealing methodology that emphasizes meeting customer requirements and facilitating development without processes that hinder work.

In my own experience, I found Scrum to be a great introductory framework full of interesting ideas, but over time, I found that the practices and values of XP were more in line with what our team actually needed to function closer to our peak performance capabilities.

In fact, my team never set out to adopt XP and we never talk about it ‒ it just so happens that most of what we decided works well overlaps with XP practices, values and principles.

With this experience in mind, I wasn’t surprised at all to read Mike Cohn write, “The XP practices are wonderful but they work best and teams commit to them the most stridently if they discover them themselves rather than having them mandated.”

Take a look at your own team practices and discussions about what works and what feels like a detractor from effective work. You may be surprised to find yourself closer to the XP side of the spectrum than you may have realized!

What’s your take? Let me know in the comments below.

The Fourth Question

 

“We are uncovering better ways of developing software by doing it and helping others do it.”

The Agile Manifesto begins with this declaration. At the centre of this mission is organizations and teams with a learning culture. In most of the agile transformations that I am involved in, we emphasize the importance of team learning and how critical it is for a self-organizing team.

In most cases, however, I have seen a good degree of individual learning. While some teams excel in team learning, my experience is that team learning remains an island of exception floating in an ocean of opportunity and necessity.

A while back, as an experiment to see if it helped individual and team learning, I suggested one of the Scrum teams add a fourth question in the standard three questions of the daily stand-up, and that was: “What did I learn yesterday?”

There may be an argument that is it too much to expect some learning every day. I honestly believe that everyone learns something every day in the adventure of doing work.

Often, we do not acknowledge this on a daily basis. My thought behind adding this question in the stand-up was to consciously cultivate a mindset of everyday learning amongst the team members. And to also acknowledge that learning happens every day.

We frequently hear to treat setbacks as a learning experience--to look at the learning behind each failure, etc. Integrating this fourth question would allow the team to create a practice of learning every day, not just when failures occur.

I observed this when I saw this particular Scrum team answer the fourth question. Answering this question increased the curiosity among other members in the team. This curiosity lead to discussions post stand-up amongst team members.

In the absence of this question, the individual learnings that are happening are not getting discussed and shared within the team adequately and often enough.

Imagine, a seven-member team sharing individual learning with others each day. The rate of team learning is going to be aggressive. More than anything else, it makes learning transparent.

Asking this fourth question is even more powerful in a distributed Scrum team. With members in a Scrum team distributed, team learning is even more challenged.

Shunryu Suzuki once said: “In the beginner’s mind there are many possibilities, in the expert’s mind there are few.”

I imagine a learning team as one which maintains a beginner’s mind even while acquiring expertise.

What do you think? Let me know in the comments below.

The Role of a Product Owner: Responsibilities & Characteristics

In the Scrum framework, the product owner is the voice of the customer, represents the internal stakeholders, and is responsible for delivering the highest possible value to the business.

In this series on the role of the product owner, I’ll help clarify product owner responsibilities and characteristics, the day-to-day work of the PO, anti-patterns that emerge in this role, and additional considerations not to be missed.

The Product Owner Overview

As the empowered lead role within the Scrum team, product owners are responsible for the product’s success. By creating, ordering and validating the list of work to be performed, the product owner has authority to decide what will be developed and when.

The ideal product owner is the person paying for the product, more generally a business-facing person is empowered to fill the role. It is important that they understand the market, product, business and any constraints involved.

By creating and communicating a clear vision, the product owner focuses the efforts of the team upon delivering the best possible customer value. Working closely with the customer and internal stakeholder, they work to bridge the gap between the business and customer needs, and the development team.

To achieve this, they must have deep customer knowledge, provide proactive stakeholder management and understand how the product is developed and delivered.

The product owner role is very demanding with significant responsibilities and as such, is generally considered full time. If you cannot devote at least half of your time to the role, then it is better to recruit someone who can.

Product Owner Responsibilities

Product owner responsibilities vary widely dependent upon the product and development environment, but include many common factors. The product owner owns all these responsibilities, but they should collaborate on them and may decide to delegate certain aspects.

Four common product owner responsibilities are:

1. Alignment on Vision

Product goal setting and the creation of a vision are the responsibility of the product owner. The vision needs to be clearly communicated with all those involved in the product including stakeholders and the development team. This enables the vision to be used when making decisions on prioritisation and direction.

2. Managing the Product Backlog

The product owner is responsible for the generation and management of the list of work to be completed by the development team. This involves writing product backlog items along with acceptance criteria, and ordering them to achieve the product vision. By making the product backlog visible to all those involved with the development, the product owner optimises work performed and ensures stakeholders understand the overall strategy and developmental roadmap.

The product backlog is the live source of all remaining work to be completed during development. It is continually updated to ensure that the team is able to deliver the most important tasks iteratively and incrementally.

3. Owning the Finances

The product owner is accountable for good economic decision-making during development at the sprint, release and product level. The iron triangle of scope, budget, time (and quality) can be traded in order to provide the best return on investment. The cost/benefit of each product backlog item can also be used to determine the ordering of work.

4. Participation in Development Events

The product owner is a key part of development events including planning, refinement, review, retrospective, the sprint and daily scrum.

During planning activities, they work with stakeholders to determine the content and steps required to deliver the next iteration at a sprint, release or product level.

Within weekly refinement sessions, they work with the development team to define, elaborate, estimate, order or delete product backlog items.

They lead reviews to ensure the product increment is examined in the optimum way to elicit feedback and determine the route forward for development.

During retrospectives, they collaborate as part of the team in determining and selecting improvement actions.

During the sprint, they work in the Scrum team, including answering questions and accepting product backlog items as they are completed. Only the product owner has authority to add or remove work from the sprint, cancel the sprint or stop overall development of the product.

They can also attend daily scrums to coordinate and collaborate with the development team on development work being performed within the sprint.

Product Owner Characteristics

There are five common characteristics for product owners:

1. Available and Engaged

A key aspect of the role is being available to answer questions from the development team. Questions can arise at any time and any delay will impact the capability of the team. The most successful projects have fully engaged product owners working daily as an integral part of the team.

2. Empowered

The organisation must empower the product owner to make decisions with the knowledge that they will be held accountable. In order to maintain the required speed of development, decision-making must be made locally at the product level. If the product owner is frequently overruled by the organisation hierarchy, then their team will start to bypass them when asking questions.

3. Decisive

The development team's questions must be answered promptly and with authority. Delaying decisions will prevent the work planned from being completed, and frequently reversing previous decisions will lead to a lack of trust. There is a balance to be made, but with the knowledge of the customer and support of internal stakeholders the product owner is in the best position to make these decisions.

4. Good Domain Knowledge

The product owner must have a good understanding of the target customers needs and appropriate business knowledge to lead development in coordination with all of the stakeholders. This requires strong support networks within the organisation and the creation of good relationships with customers and third-party suppliers.

5. Great Communication

This role requires an excellent communicator, collaborator and “people person” capable of sharing a vision, aligning people, focusing efforts and motivating the team. High emotional intelligence will help to collaborate and steer the product development to a successful conclusion.

Conclusion

In summary, within the Scrum framework the product owner:

Creates and communicates the vision, strategy and roadmap Generates a high-level release plan Forms the product backlog containing all of the work to be performed Collaborates with the team to develop and deliver the work Works with customers to review releases and adjust development accordingly Actively supports the business with progress updates and metrics

In the remainder of this series on the role of the product owner we will examine different aspects of the position:

In Part 2, we will look at the day-to-day work during a development sprint In Part 3, we examine the common anti-patterns seen for this role In Part 4, we consider the pragmatic considerations of the position

I welcome your thoughts in the comments below. 

Using 7 Product Dimensions to Slice User Stories

When listening to agile teams I coach, I hear that right-sizing user stories is one of the biggest challenges they encounter. In fact, Mike Cohn gave some advice about splitting reporting user stories, which generated a lot of comments and discussion on his blog.

Because this is such a hot topic, I was interested in attending a webinar hosted by Scrum Inc. CEO and Scrum co-creater, Jeff Sutherland, which featured Ellen Gottesdiener, titled: "Getting Your User Stories Ready: Slicing and Visualizing." Gottesdiener is co-author with Mary Gorman of the book "Discover to Deliver: Agile Product Planning and Analysis," and I’d been wanting to learn more about the seven product dimensions that I’d heard about. Gottesdiener did an excellent job of providing examples of how the seven dimensions can be applied to “slicing stories” (a term she prefers over “splitting stories”) appropriately.

Gorman and Gottesdiener have been teaching how to slice stories to optimize value for a while. In "Slicing Requirements for Agile Success," they write:

To do that [provide high-value working software], teams and business customers need to jointly explore requirements options, identify the most important ones, and slice chunky stories into manageable pieces. The optimal slicing technique would be reusable in all problem domains, leverage the discipline of requirements analysis, be quick to learn and efficient to use, engage product owners (a.k.a. customers), put the “user” back into user stories, directly feed into acceptance tests, and deepen the entire team’s knowledge of the requirements.

Gottesdiener and Gorman tend to teach by example. Their book starts out with a case study about a fictitious window cleaning company, so that the reader can see end-to-end examples of how the processes and dimensions are applied. As with any agile process, refinement continues over time with a continued cycle of discovery and delivery.

In order to create a product of high value, the seven product dimensions are used for each product option identified. Partners, falling into three groups: business, customer and technology, are identified and each group identifies the value sought from the product option. A plan is created for delivering the product option and structured conversations are used for ongoing collaborative discovery.

Regardless of initial size of the product need, which may be expressed in a variety of ways--feature, use case or story, for example--using structured conversations, alternatives are explored, which then lead to product options.

Let’s take a look at each of the seven product dimensions that are used to clarify each product option:

User: How will users will interact with the product? Interface: How will the product connect to users, systems and devices? Action: What capabilities does the product provide for users? Data: What type of data and information is needed and where is it stored? Control: What type of constraints does the product enforce? Environment: What type of physical properties and technology platforms must the product conform to? Quality attribute: What quality attributes constrain and control the product?

Gottesdiener and Gorman teach teams how to use discovery sessions with visual thinking and visual language to help stakeholders come to consensus on appropriate product requirements and how to create the right level of detail in their user stories. Using low-tech tools, sketches, diagrams, colored sticky notes and most importantly, structured conversation, teams collaboratively come together in reaching consensus on highest-value product requirements.

I’ve barely scratched the surface in this blog post on how these processes and tools can be used. The model is one that provides a systematic solution to a difficult problem. Check it out and let me know what you think!  

Size Matters in Agile

Recently, I have been working with organisations that have made things difficult for themselves by having teams that are too big, user stories that are too small or a combination of both.

While there are many differing opinions on the ideal size of either one of those things, my own preferences (on average) are the following:

A good agile team is seven, plus or minus two A good story size is about two days to one week’s effort A good task is between two and 16 hours

So, a team that is too big is:

10 or more people

And a story that is too small is:

Around one day’s effort or less as a rule of thumb

Next, let’s look at some of the issues that we might encounter if we consistently work with teams that are overly big and/or user stories that are very small.

When the Team Is Too Big

The effectiveness of team communication decreases when the team is too large. There has been lots of research in this area that can give a lot more detail than this post, so here I just want to give a few examples, especially around ceremonies.

Many people suffer, to some extent, from Glossophobia, which is a fear of public speaking. If we have big teams, our ceremonies can feel like public speaking, especially if there are also people from outside the team present.  

Some who will have very good points to contribute may not and we will lose their valuable input. In agile, we value face-to-face communication because it is very effective, so we shouldn’t create situations where people are anxious about speaking.

Another thing to consider is that all ceremonies will take longer or become rushed as teams become bigger. I have witnessed one team that was so big that their daily scrum took over 30 minutes. The Scrum Master’s answer to this was to limit everyone to essentially saying: “Yesterday I worked on Story X; today, I will continue to work on Story X.”

Anyone attempting to talk about anything else at all was advised to have a discussion later and all effective communication was lost.

Likewise, estimating and planning sessions, retrospectives and reviews are similarly impacted.

When User Stories Are Too Small

In his book “User Stories Applied,” Mike Cohn suggests that we should use the INVEST acronym to help us write good user stories. The principle is that stories should be:

Independent Negotiable Valuable Estimable Small Testable

Let’s take each one and examine some of the challenges that we might face if we try to follow Mike’s guidance when we have very small stories.

If our stories are too small, it can be difficult for them to be independent, which leads to planning and prioritization problems. In fact, having too many dependencies makes it difficult to adhere to the majority of the other principles, because to satisfy them, we would need to consider the full dependency chain.

For example, if the related stories are not yet developed, is the user story still as valuable? Can it be estimated independently? Can it be effectively tested in isolation?  

Very small stories are difficult to negotiate as they deal in the lower level detail. The acceptance criteria are no longer reminding us to have future conversations, but instead make us feel like no conversation is required. We miss a chance to have conversations and hear other viewpoints that could lead to a higher quality product.

It is not unfeasible that a small story can be very valuable by itself, but often overly small stories are of little value until their related stories are done.

I do concede that we should get more accurate estimates with smaller stories, but with an increased number of stories that contain lots of detail, those estimating sessions will be onerous and I would question if the increased accuracy would be worth this extra effort. When we estimate using story points, we are not looking for precision, just an idea of relative size.

Good user stories should be small but they shouldn’t be micro. They are small enough to be done in a sprint, but not so small that they can be done in a few hours.  

As previously mentioned, it can become difficult to make small interdependent stories testable and it often seems more efficient for testers to group these together, which suggests they could have been one story to begin with.

It is important to note that I’m not saying that we can never have a very small story, just that it should not be the norm. If we see a user story as normally being two days or more effort, it still leaves us some scope to break those stories down into meaningful tasks in a sprint planning session, discuss them in detail and estimate in hours.

When Teams Are Too Big and User Stories, Too Small

If we have a larger team, which has a larger capacity, we can do lots more small stories. If we double our team size, we will probably just about double the number of stories we aim to do. This directly results in an increased overhead being applied to almost everything we do.

It is fairly easy to imagine how our ceremonies would become even more onerous when we add more and more detailed stories for consideration. However, there are some other key areas that are now less effective:

Story boards are too busy to communicate effectively Grooming the product backlog is more difficult due to even more dependencies Re-planning or modelling are even more difficult

If we favour the technique of capacity planning (I think we should), we will find that it is very difficult to break small stories into meaningful tasks as they are task size already. What’s more, you would probably have hundreds of them. These things taken together usually means that the technique is unworkable.

In Summary

I continue to work with teams who struggle with these issues in one way or another. While I don’t think we need hard-and-fast rules for every user story, I do think we should be watchful for what could be described as an anti-patterns developing in our organisations or teams.

I would love to hear what you think and if you have any further examples where team or user story size matters; please share in the comments below.