Last week, conversations in the Scrum Facebook Group clamoured around the topic of Agile Product Development and Agile Project Development or Management.
To be honest, when I posed a question on the topic I had a hint of its significance but did not have even a glimpse of the depth of this can of worms until many more conversations, online and offline, and research on websites and YouTube on the topic.
One respected coach said to me that there may be no bigger issue than this in the Agile industry. Well then, let’s explore it a little bit.
Here I’m including three links which Facebook group members recommended. I hope these links may also be useful to other new Product Owners who are grappling with the concept of “no projects” in their work environments.
This is undoubtedly by far the very best Product Owner video I’ve seen to date. It’s just 15 minutes long. The speaker is clear and easy-to-listen to. The graphics are descriptive and simple despite representing complex ideas and systems. I came away from this video with a much more thorough and concrete understanding of the role of Product Owner.
This book is recommended by a fellow Scrum enthusiast. Amazon describes it in this way,” In Agile Product Management with Scrum,leading Scrum consultant Roman Pichler uses real-world examples to demonstrate how product owners can create successful products with Scrum. He describes a broad range of agile product management practices, including making agile product discovery work, taking advantage of emergent requirements, creating the minimal marketable product, leveraging early customer feedback, and working closely with the development team.
While I haven’t had the chance to read it yet myself, I find it reassuring that a renowned author addresses this important topic and offers his valuable insight into the conversation around Product Owner and Project Manager.
On September 09, 2016 a blog post about User stories addressed this very relevant question. The first line states, “User stories can be considered the basic units of work in organisations using an agile approach to product development.” I found this post and this website very useful in understanding the importance of user stories and how these fundamentally shift work process around delivery of value to customers.
As I set out to discover just what all the buzz is about with Product Owners I thought it’d be best if I first knew how things used to be.
It used to be that Product Managers ran the show. Wikipedia says they would, “work on specific projects that have definite outcomes, are time limited and have to stay within a budget. These roles typically include: planning what work needs to be done, when and who’s going to do it. looking at the risks involved in a particular project and managing these risks.”
Product Owners, on the other hand, “The Scrum product owner is typically a project’s key stakeholder. Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team. This is key to successfully starting any agile software development project.”
The Product Owner is primarily responsible for ordering the items in a backlog in accordance with the vision for the product.
It isn’t hard to see why the shift is not easy for some people.
Here is a short clip which demonstrates the difference nicely.
Your Product Owner needs to be informed, available, business-savvy, knowledgeable, collaborative, and empowered to make decisions about what to build and what order to do it in. They also need to be a strong negotiator and very capable at conducting business driven trade-offs. In the end, a Product Owner needs to effectively communicate, convey and deliver on a clear vision to the Team and Stakeholders to ensure a useful solution is created. Without empowerment, knowledge, and vision in a Product Owner the team will struggle. (By Senior Agile Coach Jerry Doucett)
What is agile exactly? How do we practice it? What does it look like to be an agile product owner? What is an agile team?
One of the qualities I’ve come to admire the most about agile teams and agile ambassadors is this continuous state of learning which everyone agrees to be in.
It seems as though “being agile” gives us permission to sometimes know an answer and sometimes not to. It gives us permission to sometimes understand a situation and have a solution and sometimes not to. Agile methods have a built-in “Reality Check” which is so refreshing.
By openly communicating often in retrospectives and by making work and backlog visible the process is taken out of the abstract and into the concrete. Agile seems to put everyone on the same page ~ even if people are coming at agile from very different angles.
Recently I posted a question to the 2500+ members of the Facebook Scrum group, asking for good recommendations for meaningful resources.
Dozens of individuals receive training to become Certified Scrum Product Owners at our public learning events in Toronto, Ontario.
What is a Product Owner? And how do they create a product vision in alignment with the team they work with? Xi Zeng, over at 3 Agile Guys blog, has some ideas worth sharing.
Here is an excerpt from his article on product vision.
How can a product vision help you?
A project always has a predefined scope and goals, therefore defining a vision for a project is in most of the cases not really necessary. A product has usually a much bigger scope and a longer life cycle, so it’s important to create a product vision in advance in order to:
help the business define requirements
be able to evaluate the value of the project
simplify the communication among the organisation (or with clients)
act as project’s compass
support the prioritization and decision-making in projects
The vision should consider the long term life cycle of the product and should not be easily reachable. Define even a vision that is almost impossible to reach. All short term goals should be clear defined and measurable, e.g. what is the next step in the project, next valuable goal, how to prioritize work items in backlog, etc. But the vision represents the long term future, it should stay ambitious. Just like when you’re hiking on the mountains, you can see the rocks under your feet, you know their size and form, you can touch them and even pick them up. But you can only see roughly where is the top of the mountain. While hiking, reaching the top of the mountain is our vision.
I think there is a lot of value in what Xi writes and it is worth exploring in greater depth.
After a recent large organizational change that resulted in a number of new teams formed, a product owner (PO) approached me looking for some help. He said, “I don’t think my new Scrum Master is doing their job and I’m now carrying the entire team, do we have a job description we can look at?”
I can already imagine how a version of me from a previous life would have responded, “yes of course let’s look at the job description and see where the SM is falling short of their roles and responsibilities”. But as I considered my response, my first thought was that focusing our attention on roles and job descriptions was a doomed route to failure. Pouring our energy there would likely just extend the pain the PO, and likely SM, were going through.
Sure we have an SM job description in our organization, and it clearly documents how the SM provides service to the organization, team and PO. But reviewing this with the seasoned SM didn’t really make sense to me; they were very well aware of the content of the job description and what was expected of them.
At the same time that this was happening, another newly paired Scrum Master asked for my help regarding their PO. From their perspective the PO was “suffocating” the team. The PO was directing the team in many aspects of the sprint that they felt was stepping beyond their role. “I don’t think the PO knows their role, maybe you can help me get them some training?” was the SMs concluding comment.
Over the course of the next few weeks this scenario played out again through more POs and SMs sharing similar challenges. Surely this was not a sudden epidemic of previously performing individuals who now needed to be reminded of what their job was?
Recognizing the impact of change
A common pattern was emerging from all of this, change was occurring and each individual was relying on, and to some degree expecting, old patterns to continue to work with their new situation. Their old way of working in Scrum seemed to work very well; so it was everyone else around them that was not meeting expectations.
The core issue however was that change was not being fully confronted: the product was different, the team competencies were different, the stakeholders were different, the expectations were different and finally the team dynamic was different all the way down to the relationship between the SM and PO.
Scrum as a form of Change Management
I looked for the solution from Scrum itself, at its heart a method for teams to use to adapt to and thrive with change. Was there enough transparency, inspection and adaptation going on between the SMs and POs in these situations? I would argue, not enough.
A pattern was becoming clear: nobody was fully disclosing their challenges to the other, they hadn’t fully confronted and understood their new situation and hadn’t come up with new approaches that would improve things. Said another way, they hadn’t inspected their new circumstances sufficiently and transparently enough so that they could adapt their role to fit the new need.
One thing that many successful SMs and POs recognize is that they are both leaders dependent on each other, and for their teams to be successful they need to figure out how they will work together in partnership. It doesn’t matter whether the terms of that partnership gets hashed out over a few chats over coffee or through a facilitated chartering workshop. What matters is clarity around how you agree to work together as partners meeting some shared goal.
As an SM or PO, here are some sample questions whose answers you may wish to understand and align on:
Do we both understand and support the team’s mission and goals?
What are the product goals?
How can we best help the team achieve those goals?
Are there any conflicts between the team and product goals?
When our goals or methods are in conflict, how will we resolve them?
In what ways will I be supporting your success as an SM/PO?
How will we keep each other informed and engaged?
Should we have a peer/subordinate/other relationship?
So if you are an SM or PO, and it’s unclear to you on the answers to some of these questions, you may just want to tap your leadership partner on the shoulder and say “let’s talk”.
As a product owner, what are the best ways to record technical debt and what are some approaches to prioritizing that work amid the continuous delivery of working software?
Answer:
Hi Meredith! This is an interesting question. I’ll start by answering the second part of your question first. The two most common ways of handling technical debt, quality debt and legacy debt are:
Fix as you go. The Scrum Team works on new PBIs every Sprint, but every time a PBI touches a technical, quality or legacy debt area, the team fixes “just enough” to make the PBI implementation have no debt. This means that refactoring and the creation of automated tests (usually through TDD) are done on the parts of the product/system that have the problems.
Allocate a percentage. In this scenario, the Scrum Team reduces its velocity (sometimes significantly) to allow for time to deal with the technical, quality and legacy issues. This reduction could be adjusted every Sprint, but is usually consistent for several Sprints in a row.
In both approaches, the business is paying for the debt accumulated, and the cost includes an “interest” fee. In other words, the sooner you fix technical, quality and legacy debt, the less it costs. This approach to thinking about your product/system is essential for long-term sustainability. One organization I worked with took three years working on their system to clean it up without being able to add any new features! Don’t let your system get to that point.
Now to the first part of your question…
As a Product Owner, you shouldn’t really be making decisions about this cleanup work. Your authority is limited to the Product Backlog which should not include technical items. The only grey area here is with defects which may be hard to classify as either fully business or fully technical. But technical design, duplication of code, technical defects, and legacy code all are under the full authority of the Scrum Development Team. Practically, this means that every Sprint the team has the authority to choose however few PBIs they feel they can take while considering the technical state of the product/system. We trust and respect the team to make wise decisions.
Therefore, your main job as a Product Owner is to provide the team with as much information as possible about the business consequences of the work they are doing. With strong communication and collaboration about this aspect of their work, the technical members of your team can make good trade-off decisions, and balance the need for new features with the need to clean up previous compromises in quality.
A final note: in order for this to work well, it is critical that the team not be pushed to further sacrifice quality and that they are given the support to learn the techniques and skills to create debt-free code. (You might consider sending someone to our CSD training to learn these techniques and skills.)
Using these techniques, I have been able to help teams get very close to defect-free software deliveries (defect rates of 1 or 2 in production per year!)
Let me know in the comments if you would like any further clarification.
On many occasions, I have observed “Scrum Masters” and even “Product Owners” attempting to drive what they understand to be the Daily Scrum. Just this morning, I witnessed a “Daily Scrum” in which a “Product Owner” gave the team a bunch of program updates and made sure that each team member had tasks to work on for the day. Then, the PO “wrapped up” the meeting and left the team to get to the work. I then stayed and observed what the team did next. They actually stayed together to discuss the work and figure out how they were going to organize themselves for the day. I then went over to the Product Owner and whispered in her ear that the team was now doing the real Daily Scrum. She said “Oh,” and promptly walked over to find out what was going on. I then observed her from a distance nodding her head several times while appearing to understand what the team was talking about. I’m not sure if she understood or not, but that’s irrelevant. The point is that the Daily Scrum is for the Development Team to inspect and adapt its progress towards the Sprint Goal and decide how it will self-organize for the coming day. If the Development Team decides as a result of the Daily Scrum that it needs to re-negotiate any previously forcasted functionality with the Product Owner, then that conversation can certainly happen at that time.
The Product Owner is a full member of the Scrum Team and should be present at all Scrum meetings (Sprint Planning, Daily Scrums, Sprint Review and Sprint Retrospective). As well, the Product Owner should also be available during work time. Of course, the PO also needs to work with stakeholders and might be away during that time, but these discussions should be scheduled outside of the team’s meeting times.
In one case with a team I was coaching at Capital One, the Product Owner didn’t show up for the Sprint Review and then didn’t show up for the Sprint Planning meeting. The rest of the team decided to delay the start of the Sprint until the Product Owner did show up. The director-level manager of the team, a deeply insightful individual, insisted that all team members take paid days off until the Product Owner was ready to attend the Sprint Review… kind of like a mini-strike. It only took two days for the Product Owner to clear his schedule to attend the Sprint Planning meeting.
Product Owner as Scrum Team Member
The Scrum Guide defines the membership of the Scrum Team as follows:
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team…. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.
As a member of the Scrum Team, the product owner should have the same level of commitment, courage, focus, openness, and respect (the five Scrum values) as any other Scrum Team member. The Product Owner needs to collaborate actively with the Scrum Team. One way to gauge the involvement of the Product Owner is in the Sprint Review. If the Product Owner is giving feedback to the rest of the Team in the Sprint Review, it’s too late! The Product Owner should never be surprised by the product increment shown in the Sprint Review. Instead, the Product Owner should be leading the discussion to get feedback from customers, users and other stakeholders during the Sprint Review.
Being Away from the Team
There are some interesting exceptions to the Product Owner being present. Here are some of the most common:
The Product Owner needs to be away from the team to work directly with customers, users, sales teams, marketing, customer service people, etc. This work is essential for making sure that the Product Backlog contains the most up-to-date information every Sprint. This time away should normally be scheduled outside of the Scrum meeting times.
The Product Owner may need to travel to meet with customers and be away from the Scrum Team for an extended period of time.
Of course, like any other team member, the Product Owner can and should take vacation and may be ill from time-to-time. This may seem trivially obvious. What is not obvious is that it often helps the team to leave another team member with temporary responsibility to fill in for the Product Owner. This temporary fill-in should not be someone from outside the team.
Special Case: The Daily Scrum Meeting
The latest version of the Scrum Guide also puts the Daily Scrum meeting in a special category. The meeting is for the Development Team (the subset of the Scrum Team that excludes the ScrumMaster and the Product Owner). Former versions of the Scrum Guide and other official Scrum documentation have changed this rule in various ways. As a personal comment, I believe this is a serious internal contradiction in the definition of Scrum. If the Scrum Team is self-organizing, then the Daily Scrum should include the ScrumMaster and Product Owner. I have seen this work successfully. The Scrum Guide says nothing about other people observing the Daily Scrum. I strongly recommend that the ScrumMaster and Product Owner observe the meeting even if you wish to follow Scrum strictly and restrict their participation.
If you decide to allow the Product Owner to participate in the meeting, then the Product Owner should restrict their comments to changes in the Product Backlog that require the team’s help for refinement. For example, the Product Owner could report in the Daily Scrum as follows:
“Yesterday I met with Sanjay at Deal Maker Industries and he suggested that we add a feature to allow car manufacturers to ping various stakeholders about risks and options. I think that will mean adding several new user stories to the Product Backlog. I need help from the team to write and estimate the new PBIs. Today I also have a re-prioritization meeting with three key internal stakeholders. My only obstacle is that I still can’t get a meeting with Karen about the marketing of the features from our last few Sprints and I’m worried that will delay our next release.”
In this example, the team and the ScrumMaster are kept apprised of key developments at the product level and know that there will be some extra work during the day to work on Product Backlog Refinement. The Scrum Guide says:
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Balance in the Product Owner Role
Ideally, the Product Owner would spend an equal amount of time with their Scrum Team and with outside customers and users. The Product Owner is the key conduit of information from the market to the Development Team. Not being present with the Scrum Team can hinder this flow of information and cause quality problems and unnecessary rework. Again, the Product Owner should never be surprised in the Sprint Review.
Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should be assigning tasks to team members. Don’t do this!!! It is better to wait for someone to step up than to “take over” and start assigning tasks.
Assigning tasks can be overt or subtle. Therefore, avoid even suggestions that could be taken as assigning tasks. For example, no one should ever tell a Scrum Team member “hey! You’re not doing any work – go take a task!” (overt) or “This task really needs to get done – why don’t you do it?” (semi-overt) or “Would you consider working on this with me?” (subtle). Instead, any reference to tasks should be to the team at large. For example it would be okay for a team member to say “I’m working on this and I would like some help – would anyone help me?”
In the Scrum Guide, a partial definition of self-organizing is given:
Scrum Teams are self-organizing….. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
A more formal definition of the concept of “self-organizing” can be found here:
Self-organisation is a process where some form of global order or coordination arises out of the local interactions between the components of an initially disordered system. This process is spontaneous: it is not directed or controlled by any agent or subsystem inside or outside of the system; however, the laws followed by the process and its initial conditions may have been chosen or caused by an agent.
The key here is that there is no single point of authority, even temporarily, in a self-organizing team. Every individual member of the team volunteers for tasks within the framework of “the laws followed by the process” – namely Scrum. Scrum does define some constraints on individual behaviour, particularly for the Product Owner and the ScrumMaster. People in those two roles have specific duties which usually prevent them from being able to volunteer for any task. But all the other team members (the Development Team) have complete freedom to individually and collectively figure out how they will do the work at hand.
What If One Person Isn’t Working?
People who are managers are often worried about this. What if there is one person on the team who just doesn’t seem to be doing any work? Isn’t assigning tasks to this person a good thing? Scrum will usually make this bad behaviour really obvious. Let’s say that Alice hasn’t completed any tasks in the last four days (but she does have a task that she volunteered for at the start of the Sprint). Raj notices that Alice hasn’t finished that initial task. An acceptable solution to this problem is for Raj to volunteer to help Alice. Alice can’t refuse the help since Raj is self-organizing too. They might sit together to work on it.
Of course, that might not solve the problem. So another technique to use that respects self-organization is to bring it up in the Sprint Retrospective. The ScrumMaster of the team, Sylvie, chooses a retrospective technique that is designed to help the team address the problem. In a retrospective, it is perfectly acceptable for people on the team to be direct with each other. Retrospectives need to be safe so that this kind of discussion doesn’t lead to animosity between team members.
Remember: everyone goes through ups and downs in productivity. Sometimes a person is overwhelmed by other aspects of life. Sometimes a person is de-motivated temporarily. On the other hand, sometimes people become extremely engaged and deliver exceptional results. Make sure that in your team, you give people a little bit of space for these ups and downs. Assigning tasks doesn’t make a person more productive.
What If There is One Task No One Wants to Do?
Dig deep and find out why no one wants to do it. This problem is usually because the task itself is worthless, frustrating, repetitive, or imposed from outside without a clear reason. If no one wants to do a task, the first question should always be: what happens if it doesn’t get done? And if the answer is “nothing bad”… then don’t do it!!!
There are, unfortunately, tasks that are important that still are not exciting or pleasant to do. In this situation, it is perfectly acceptable to ask the team “how can we solve this problem creatively?” Often these kinds of tasks can be addressed in new ways that make them more interesting. Maybe your team can automate something. Maybe a team member can learn new skills to address the task. Maybe there is a way to do the task so it never has to be done again. A self-organizing Scrum Team can use innovation, problem-solving and creativity skills to try to over come this type of problem.
And, of course, there’s always the Sprint Retrospective!
Why Self-Organize – Why Is Assigning Tasks Bad?
Autonomy is one of the greatest motivators there is for people doing creative and problem-solving types of work. The ability to choose your own direction instead of being treated like a mushy, weak, unreliable robot. Motivation, in turn, is one of the keys to creating a high-performance state in individuals and teams. The greatest outcome of good self-organization is a high-performance team that delivers great work results and where everyone loves the work environment.
Assigning tasks to people is an implicit claim that you (the assigner) know better than them (the assignees). Even if this is true, it is still easy for a person to take offence. However, most of the time it is not true. People know themselves best. People are best at assigning tasks to themselves. And therefore, having one person assigning tasks to other people almost always leads to sub-optimal work distribution among the members of a team.
The ScrumMaster and Assigning Tasks
The ScrumMaster plays an important role in Scrum. Part of this role is to encourage self-organization on a team. The ScrumMaster should never be assigning tasks to team members under any circumstances. And, the ScrumMaster should be protecting the team from anyone else who is assigning tasks. If someone within the team is assigning tasks to another team member, the ScrumMaster should be intervening. The ScrumMaster needs to be constantly aware of the activity on his or her team.
I have added a video to YouTube that you might consider sharing with ScrumMasters you know about this topic:
Regular big up-front planning is not necessary with Scrum. Instead, a team can just get started and use constant feedback in the Sprint Review to adjust it’s plans. Even the Product Backlog can be created after the first Sprint has started. All that is really necessary to get started is a Scrum Team, a product vision, and a decision on Sprint length. In this extreme case, the Scrum Team itself would decide what to build in its first Sprint and use the time of the Sprint to also prepare some initial Product Backlog Items. Then, the first Sprint Review would allow stakeholders to provide feedback and further develop the Product Backlog. The empirical nature of Scrum could even allow the Product Owner to emerge from the business stakeholders, rather than being assigned to the team right from the start.
Starting a Sprint without a Product Backlog is not easy, but it can be done. The team has to know at least a little about the business, and there should be some (possibly informal) project or product charter that they are aware of. The team uses this super basic information and decides on their own what to build in their first Sprint. Again, the focus should be on getting something that can be demoed (and potentially shippable). The team is likely to build some good stuff and some things that are completely wrong… but the point is to get the Inspect and Adapt cycle started as quickly as possible. Which means of course that they need to have stakeholders (customers, users) actually attend the demo at the end of the Sprint. The Product Owner may or may not even be involved in this first Sprint.
One important reason this is sometimes a good approach is the culture of “analysis paralysis” that exists in some organizations. In this situation, an organization is unable to do anything because they are so concerned about getting things right. Scrum is a framework for inspect and adapt and that can (and does) include the Product Backlog. Is it better for a team to sit idle while someone tries to do sufficient preparation? Or is it better to get started and inspect and adapt? This is actually a philosophical question (as well as a practical question). The mindset and philosophy of the Agile Manifesto and Scrum is that trying to produce valuable software is more important that documentation… that individuals and how they work together is more important than rigidly following a process or tool. I will agree that in many cases it is acceptable to do some up-front work, but it should be minimized, particularly when it is preventing people from starting to deliver value. The case of a team getting started without a product backlog is rare… but it can be a great way for a team to help an organization overcome analysis paralysis.
The Agile Manifesto is very clear: “The BEST architectures, requirements and designs emerge out of self-organizing teams.” [Emphasis added.]
Hugely memorable for me is the story that Ken Schwaber told in the CSM course that I took from him in 2003. This is a paraphrase of that story:
I [Ken Schwaber] was talking to the CIO of a large IT organization. The CIO told me that his projects last twelve to eighteen months and at the end, he doesn’t get what he needs. I told him, “Scrum can give you what you don’t need in a month.”
I experienced this myself in a profound way just a couple years into my career as an Agile coach and trainer. I was working with a department of a large technology organization. They had over one hundred people who had been working on Agile pilot projects. The department was responsible for a major product and executive management had approved a complete re-write. The product managers and Product Owners had done a lot of work to prepare a product backlog (about 400 items!) that represented all the existing functionality of the product that needed to be re-written. But, the big question, “what new technology platform do we use for the re-write?” had not yet been resolved. The small team of architects were tasked with making this decision. But they got stuck. They got stuck for three months. Finally, the director of the department, who had learned to trust my advice in other circumstances, asked me, “does Scrum have any techniques for making these kind of architectural decisions?”
I said, “yes, but you probably won’t like what Scrum recommends!”
She said, “actually, we’re pretty desperate. I’ve got over a hundred people effectively sitting idle for the last three months. What does Scrum recommend?”
“Just start. Let the teams figure out the platform as they try to implement functionality.”
She thought for a few seconds. Finally she said, “okay. Come by this Monday and help me launch our first Sprint.”
The amazing thing was that the teams didn’t lynch me when on Monday she announced that “our Agile consultant says we don’t need to know our platform in order to get started.”
The first Sprint (two weeks long) was pretty chaotic. But, with some coaching and active support of management, they actually delivered a working increment of their product. And decided on the platform to use for the rest of the two-year project.
You must trust your team.
If your organization is spending more than a few days preparing for the start of a project, it is probably suffering from this pitfall. This is the source of great waste and lost opportunity. Use Scrum to rapidly converge on the correct solutions to your business problems instead of wasting person-years of time on analysis and planning. We can help with training and coaching to give you the tools to start fast using Scrum and to fix your Scrum implementation.
Becoming familiar with the “User Story” approach to formulating Product Backlog Items and how it can be implemented to improve the communication of user value and the overall quality of the product by facilitating a user-centric approach to development.
Consider the following
User stories trace their origins to eXtreme Programming, another Agile method with many similarities to Scrum. Scrum teams often employ aspects of eXtreme Programming, including user stories as well as engineering practices such as refactoring, test-driven development (TDD) and pair programming to name a few. In future modules of this program, you will have the opportunity to become familiar enough with some of these practices in order to understand their importance in delivering quality products and how you can encourage your team to develop them. For now, we will concentrate on the capability of writing good user stories.
A User Story has three primary components, each of which begin with the letter ‘C’:
Card
The Card, or written text of the User Story is best understood as an invitation to conversation. This is an important concept, as it fosters the understanding that in Scrum, you don’t have to have all of the Product Backlog Items written out perfectly “up front”, before you bring them to the team. It acknowledges that the customer and the team will be discovering the underlying business/system needed as they are working on it. This discovery occurs through conversation and collaboration around user stories.
The Card is usually follows the format similar to the one below
As a <user role> of the product,
I can <action>
So that <benefit>.
In other words, the written text of the story, the invitation to a conversation, must address the “who”, “what” and “why” of the story.
Note that there are two schools of thought on who the <benefit> should be for. Interactive design specialists (like Alan Cooper) tell us that everything needs to be geared towards not only the user but a user Persona with a name, photo, bio, etc. Other experts who are more focused on the testability of the business solution (like Gojko Adzic) say that the benefit should directly address an explicit business goal. Imagine if you could do both at once! You can, and this will be discussed further in more advanced modules.
Conversation
The collaborative conversation facilitated by the Product Owner which involves all stakeholders and the team.
As much as possible, this is an in-person conversation.
The conversation is where the real value of the story lies and the written Card should be adjusted to reflect the current shared understanding of this conversation.
This conversation is mostly verbal but most often supported by documentation and ideally automated tests of various sorts (e.g. Acceptance Tests).
Confirmation
The Product Owner must confirm that the story is complete before it can be considered “done”
The team and the Product Owner check the “doneness” of each story in light of the Team’s current definition of “done”
Specific acceptance criteria that is different from the current definition of “done” can be established for individual stories, but the current criteria must be well understood and agreed to by the Team. All associated acceptance tests should be in a passing state.
The test for determining whether or not a story is well understood and ready for the team to begin working on it is the INVEST acronym:
I – Independent
The solution can be implemented by the team independently of other stories. The team should be expected to break technical dependencies as often as possible – this may take some creative thinking and problem solving as well as the Agile technical practices such as refactoring.
N – Negotiable
The scope of work should have some flex and not be pinned down like a traditional requirements specification. As well, the solution for the story is not prescribed by the story and is open to discussion and collaboration, with the final decision for technical implementation being reserved for the Development Team.
V – Valuable
The business value of the story, the “why”, should be clearly understood by all. Note that the “why” does not necessarily need to be from the perspective of the user. “Why” can address a business need of the customer without necessarily providing a direct, valuable result to the end user. All stories should be connected to clear business goals. This does not mean that a single user story needs to be a marketable feature on its own.
E – Estimable
The team should understand the story well enough to be able estimate the complexity of the work and the effort required to deliver the story as a potentially shippable increment of functionality. This does not mean that the team needs to understand all the details of implementation in order to estimate the user story.
S – Small
The item should be small enough that the team can deliver a potentially shippable increment of functionality within a single Sprint. In fact, this should be considered as the maximum size allowable for any Product Backlog Item as it gets close to the top of the Product Backlog. This is part of the concept of Product Backlog refinement that is an ongoing aspect of the work of the Scrum Team.
T – Testable
Everyone should understand and agree on how the completion of the story will be verified. The definition of “done” is one way of establishing this. If everyone agrees that the story can be implemented in a way that satisfies the current definition of “done” in a single Sprint and this definition of “done” includes some kind of user acceptance test, then the story can be considered testable.
Note: The INVEST criteria can be applied to any Product Backlog Item, even those that aren’t written as User Stories.
Splitting Stories:
Sometimes a user story is too big to fit into a Sprint. Some ways of splitting a story include:
Split by process step
Split by I/O channel
Split by user options
Split by role/persona
Split by data range
WARNING: Do not split stories by system, component, architectural layer or development process as this will conflict with the teams definition of “done” and undermine the ability of the team to deliver potentially shippable software every Sprint.
Personas
Like User Stories, Personas are a tool for interactive design. The purpose of personas is to develop a precise description of our user and so that we can develop stories that describe what he wishes to accomplish. In other words, a persona is a much more developed and specific “who” for our stories. The more specific we make our personas, the more effective they are as design tools.iii
Each of our fictional but specific users should have the following information:
Name
Occupation
Relationship to product
Interest & personality
Photo
Only one persona should be the primary persona and we should always build for the primary persona. User story cards using personas replace the user role with the persona:
<persona>
can <action>
so that <benefit>.
i The Card, Conversation, Confirmation model was first proposed by Ron Jeffries in 2001.
iiINVEST in Good Stories, and SMART Tasks. Bill Wake. http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
iiiThe Inmates are Running the Asylum. Alan Cooper. Sams Publishing. 1999. pp. 123-128.
May people have concerns about the possibility of using Scrum or other Agile methods on large projects that don’t directly involve software development. Data warehousing projects are commonly brought up as examples where, just maybe, Scrum wouldn’t work.
I have worked as a coach on a couple of such projects. Here is a brief description of how it worked (both the good and the bad) on one such project:
The project was a data warehouse migration from Oracle to Teradata. The organization had about 30 people allocated to the project. Before adopting Scrum, they had done a bunch of up-front analysis work. This analysis work resulted in a dependency map among approximately 25,000 tables, views and ETL scripts. The dependency map was stored in an MS Access DB (!). When I arrived as the coach, there was an expectation that the work would be done according to dependencies and that the “team” would just follow that sequence.
I learned about this all in the first week as I was doing boot-camp style training on Scrum and Agile with the team and helping them to prepare for their first Sprint.
I decided to challenge the assumption about working based on dependencies. I spoke with the Product Owner about the possible ways to order the work based on value. We spoke about a few factors including:
retiring Oracle data warehouse licenses / servers,
retiring disk space / hardware,
and saving CPU time with new hardware
The Product Owner started to work on getting metrics for these three factors. He was able to find that the data was available through some instrumentation that could be implemented quickly so we did this. It took about a week to get initial data from the instrumentation.
In the meantime, the Scrum teams (4 of them) started their Sprints working on the basis of the dependency analysis. I “fought” with them to address the technical challenges of allowing the Product Owner to work on the migration in order based more on value – to break the dependencies with a technical solution. We discussed the underlying technologies for the ETL which included bash scripts, AbInitio and a few other technologies. We also worked on problems related to deploying every Sprint including getting approval from the organization’s architectural review board on a Sprint-by-Sprint basis. We also had the teams moved a few times until an ideal team workspace was found.
After the Product Owner found the data, we sorted (ordered) the MS Access DB by business value. This involved a fairly simple calculation based primarily on disk space and CPU time associated with each item in the DB. This database of 25000 items became the Product Backlog. I started to insist to the teams that they work based on this order, but there was extreme resistance from the technical leads. This led to a few weeks of arguing around whiteboards about the underlying data warehouse ETL technology. Fundamentally, I wanted to the teams to treat the data warehouse tables as the PBIs and have both Oracle and Teradata running simultaneously (in production) with updates every Sprint for migrating data between the two platforms. The Technical team kept insisting this was impossible. I didn’t believe them. Frankly, I rarely believe a technical team when they claim “technical dependencies” as a reason for doing things in a particular order.
Finally, after a total of 4 Sprints of 3 weeks each, we finally had a breakthrough. In a one-on-one meeting, the most senior tech lead admitted to me that what I was arguing was actually possible, but that the technical people didn’t want to do it that way because it would require them to touch many of the ETL scripts multiple times – they wanted to avoid re-work. I was (internally) furious due to the wasted time, but I controlled my feelings and asked if it would be okay if I brought the Product Owner into the discussion. The tech lead allowed it and we had the conversation again with the PO present. The tech lead admitted that breaking the dependencies was possible and explained how it could lead to the teams touching ETL scripts more than once. The PO basically said: “awesome! Next Sprint we’re doing tables ordered by business value.”
A couple Sprints later, the first of 5 Oracle licenses was retired, and the 2-year $20M project was a success, with nearly every Sprint going into production and with Oracle and Teradata running simultaneously until the last Oracle license was retired. Although I don’t remember the financial details anymore, the savings were huge due to the early delivery of value. The apprentice coach there went on to become a well-known coach at this organization and still is a huge Agile advocate 10 years later!
The Product Owner Simulation that I shared last summer has some minor updates based on a stronger emphasis on product vision. In particular, two 5 minute exercises before and after the Product Box exercise help to frame the concept of product vision and make it stronger.
“Agile Product Management with Scrum: Creating Products that Customers Love,” by Roman Pichler.
