As a Team Member, it is my job to figure out how to solve a problem or request that is stated by a Product Backlog Item (PBI), with the help of my team. It is the responsibility of the Product Owner to give us the vision of the product and decide how much scope is to be done to satisfy the PBI. One simple way to think about this concept is that the Product Owner is responsible for the “what” and “why” and the Scrum Team is responsible for the “how” and “who”. If the Team Members decide on the product vision by themselves, they run the risk of misinterpreting features, moving down a path that is not valuable or even creating work disconnected from the needs of those who will be using the software. If the Team Members choose their own scope they may do much less than is needed or much more than is required. There is a balance in the Product Owner providing vision and scope, and the Scrum Team providing knowledge and experience in its execution.
Product Backlog Items closest to the top of the Product Backlog should be small enough for the team to be able to complete at least one potentially shippable slice of the product in the next Sprint. As well, they should be ready for the Sprint Planning meeting so that the team can plan its work for the Sprint. To be ready for the Sprint Planning Meeting, each PBI must be estimated. Generally speaking, Product Backlog Items at the top of the Product Backlog are clearer and more detailed than lower ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are fine-grained, having been decomposed so that at least one item can be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “ready” or “actionable” for selection in a Sprint Planning Meeting. Having too many items in the Product Backlog “ready” for the team is considered wasteful over-planning, although generally the top ten items should be in this “ready” state. The value of having a refined Product Backlog before the Spring Planning Meeting is that it enables the Scrum team to focus on the purpose of the Sprint Planning Meeting which is to answer these questions: What will be delivered in the Increment resulting from the upcoming Sprint and how will the work needed to deliver the Increment be achieved? Essentially, what is the Spring goal and what are the tasks needed to complete the goal? Without a ready Product Backlog, the purpose of the Sprint Planning Meeting is difficult to achieve.
Product Backlog Items are brief descriptions of a feature or function. Usually they are short enough that they could be hand-written on a small note card. This brevity is meant to be just enough information so that the Product Owner and the team can use the PBIs as invitations to conversations. The resulting conversation (ongoing, evolving and involving the whole team and stakeholders) and the shared understanding that comes from that conversation is where the real value of the PBI resides. Part of the conversation occurs when the Product Owner initially writes the PBI so that the team can estimate the effort of building it. Part of the conversation is the actual work being done during a Sprint. Another part of the conversation is during the Sprint Review when stakeholders see the results of the team building the PBIs. If one creates PBIs as detailed specifications then we are essentially handcuffing the team into a set path and a prescriptive solution. The reason we hire qualified people onto our Scrum Team is for their knowledge, experience, and problem solving abilities. If we lock them into a set path, then we are literally turning them into cogs in a machine to spit out specific code. PBIs that are invitations to conversations allow them the flexibility to figure out how to solve the problem by engaging in a conversation on what is needed.
There are three roles on a Scrum Team, no more and no less. These roles are: ScrumMaster, Product Owner, and the Team Members. It is critical to have all three roles present on the Scrum Team to get all needed responsibilities taken care of in an effective way. The Product Owner is responsible for the product and how the team connects with that product. The ScrumMaster is responsible for improving the use of Scrum in the organization and team, as well as removing any obstacles that slow the team down. The Team Members are responsible for getting the work done by self-organizing and finding ways to improve their own process and work. Without one of these key roles, the team would be missing a key focus and job. As well, Scrum specifically disallows any other roles on the Scrum Team. A person who has an official role of Tester cannot be on a Scrum Team. However, the same person, if given the official role of Team Member can be on a Scrum Team. If people have their official titles, performance evaluations etc. done in their traditional roles, it hinders self-organizing and causes conflicts of interest. A team is not a Scrum Team until those old roles are eliminated.
Scrum is the most popular agile method… if you count all of the teams doing “Scrum Butt”. Doing Scrum really well is much harder and much rarer. Here is a list of 24 common pitfalls or bad behaviours of Scrum teams:
- Excessive Preparation/Planning: 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.
- Focus On Tools: Many organizations try to find an electronic tool to help them manage the Scrum Process… before they even know how to do Scrum well! Use manual and paper-based tracking for early Scrum use since it is easiest to get started. Finding a tool is usually just an obstacle to getting started. (And besides, check out what the Agile Manifesto says about tools.)
- Problem-Solving in the Daily Scrum: The Daily Scrum should not be used to find solutions to problems (obstacles, impediments) raised. Instead, keep the meeting very short and have those problem-solving conversations afterwards with only those who are interested. The ScrumMaster facilitates this meeting to keep it on track.
- Assigning Tasks: 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 assign tasks to team members. It is better to wait for someone to step up than to “take over” and assign a task.
- Failed Sprint Restart: Although cancelling a Sprint is rare, it can be tempting to try and wait until everything is “perfect” or “ready” before re-starting. Teams should immediately re-start after cancelling a Sprint.
- ScrumMaster As Contributor: The ScrumMaster is like a fire-fighter: it’s okay for them to be idle – just watching the team – waiting for an emergency obstacle. Taking on tasks tends to distract the ScrumMaster from the job of helping the team follow the rules of Scrum, from the job of vigorously removing obstacles, and from the job of protecting the team from interruptions.
- Product Owner Doesn’t Show: The Product Owner is a full member of the team and should be present at all Scrum meetings (Planning, Review and Daily Scrums). 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.
- Stretch Goals: The team decides on how much work it will do in a Sprint. No one should bring pressure on the team to over-commit. This simply builds resentment, distrust and encourages low-quality work. That said, of course teams can be inspired by challenging overall project or product goals.
- Individual Heroics: Individuals on a Scrum team should not do excessive individual overtime, or in any other way try to be the “hero” of the team. Scrum helps us build great teams of people, not teams of great people (quote from Barry Turner).
- Team Organizes Product Backlog: The team does not have proper insight into the needs of users and instead should be focused on solving technical problems. The Product Owner needs to be accountable for ROI and therefore should resist any pressure from the team to do things in a particular order for “technical” reasons.
- Product Owner Specifies Solutions: The Product Owner must allow the team full freedom to come up with solutions to the problems presented in the Product Backlog. PBIs should be free of technical specifications unless they can be tied directly to a customer or end-user request.
- Urgent Interruptions: Urgent interruptions should not be allowed in a Sprint… instead, if it is urgent enough, the team should cancel the Sprint. Otherwise, the interruption should be put on the Product Backlog and deferred until the start of the next Sprint.
- Making Assumptions: Often team members will fail to ask the Product Owner about details of the work they are doing. A team member solves problems, but it is critical to know about constraints. The feedback between PO and Team Member should be ongoing throughout every day of the Sprint.
- Not Getting Done: This is hard to prevent from happening from time to time, but it can become a habit for a team to over-commit. Make sure that a team that is doing this is using burndown charts effectively and is holding demos even when they have not completed all their work.
- Demo Not Ready: Sometimes a team forgets that it will take time to prepare for a demo: cleaning the team space, setting up a demonstration environment, getting scripts ready, and ensuring that critical stakeholders are prepped. These activities can be part of the tasks in the Sprint Backlog.
- Prototype Not Shippable: A Scrum team should attempt to produce production-quality, “potentially shippable” software right from the very first Sprint. Building prototype code just delays the inevitable need to write production code. Similarly, wireframes, detailed designs and other similar tools should also be avoided.
- Distributed Team: Although Scrum does not officially require team members to be collocated in a “war room”, the reality is that any distribution of team members (even just into separate cubicles) has a huge negative impact on transparency and communication, which in turn has a huge impact on productivity and quality.
- Directive ScrumMaster: The ScrumMaster needs to be a facilitator who supports the team in learning self-organization, and the Scrum rules. The ScrumMaster should never succumb to the temptation to suggest how a team member does his or her work, nor what task next to work on.
- Changing Team Membership: Scrum is a framework for creating high-performance product development teams. If the membership of a Scrum team changes, it forces that team to re-start the Forming-Storming-Norming-Performing sequence. If the team is in Norming or Performing, then changing team membership for any reason is a waste of quite an investment.
- Non-Scrum Roles on the Scrum Team: It is very common for an organization to create a Scrum team without changing the official title and duties of the people who are members of that team. For example, a person who is a Project Manager might be given the responsibilities of the Product Owner without an official change of title. Scrum teams should only have a ScrumMaster, a Product Owner, and Team Members.
- Giving Up On Quality: Scrum has very high demands on teams regarding the quality of their results: “potentially shippable software”. It is easy for a team or organization to fall back on the crutch of defect tracking software instead of maintaining extremely high levels of quality at all times (due to pressure to release features).
- Imposed Deadline Scope And Resources: Scrum is reality-based. If an external stakeholder wants to impose a minimum scope, a deadline and constrain the resources available to the team then they must allow that quality will slip… which in turn is against the principles of Scrum. The reality is that no-one can predict the future so any such imposition is simply a fantasy.
- Definition of “Done” Imposed: There is confusion between the concept of the definition of “done” and “standards”. Managers and other stakeholders often incorrectly impose standards on a team as its definition of “done”.
- ScrumMaster Not Present: I once saw an organization that had created a room for a “team” of ScrumMasters. They worked there together most of the time! The only time the ScrumMaster should be away from the team is when he/she is working on removing an impediment that is outside the team. Otherwise, the ScrumMaster should be in the team’s room.
From time to time I am happy to list positions that are available in organizations that are becoming agile or already are agile. For what it’s worth, this position was described verbally to me as being much like a Scrum Product Owner. Here is the position information:
Project Manager at zu
Closing date: Monday, May 30, 2011
Our new Agile PM will manage full life cycle website/application development projects using the Agile methodology, work closely with our strategists, designers and development team and other stakeholders to manage requirements, scope, milestones, timelines and budget.
As an Agile Project Manager at zu, you enjoy working with other talented people and succeed when we deliver a project worthy of being called “zu-made” to a client. You live to under promise and over deliver.
You have a passion for Agile Software Development. You are eager to work with and share your experiences with a team transitioning to Agile. The thought of finding new ways to adapt Agile to an existing team excites you.
As a team leader, you inject enthusiasm into the combined zu-client team, adding transparency and candidness to communication in all directions. Using your natural ability to develop rapport with all types of people, you liaise regularly with the client and team, keeping progress on track and delivering on expectations.
You are excited by the idea of creating things that have never existed before, that learning and teaching are everyday occurrences, you don’t mind dressing funny from time to time, or bringing a dish to the potluck.
If you have the required experience, pride yourself on being extremely well organized, have a magnetic personality, sense of humor and are eager to be a part of an evolving company, then what are you waiting for? Drop us a line!
Post secondary education in business or technical field
Minimum three years related work experience
Knowledge and experience with Agile software development, processes and methodology
Ability to work effectively on concurrent, multiple tasks and projects
Ability to effectively manage priorities in an ever-changing environment
Outstanding leadership and teamwork skills
Clear and concise documentation skills; you can write mean user story
Strong verbal and written communication skills
Document, learn and support all aspects of projects: scope, risk, schedule, budget, quality and communication
Manage client expectations and co-ordinate and deliver progress updates to ensure the successful delivery of projects on time and on budget
Manage all project related requests with the client
Ability to guide and direct production teams to keep them on budget and schedule while continually inspiring them to innovate and provide the best solutions for our clients
Work with development teams on a daily basis to clarify requirements and to provide feedback
Facilitate developing user stories based on requirements
Prioritize and prepare product backlog and facilitate estimation meetings for strategists, designers and developers
Communicate project status with stakeholders and gather feedback for review and implementation
For more information about zu, head to our website: www.zu.com/live/careers.
Due to popular demand, we have added another Certified Scrum Product Owner (CSPO) training to our listing of courses. There is an overwhelming need for well trained Product Owners, and we’re happy to take up the challenge. The next CSPO will happen on January 14 & 15 at our office in Newmarket, just north of Toronto.
During this seminar, our Certified Scrum Trainer will teach participants how to do the fundamental tasks of the Product Owner in the Scrum environment. The attendees will learn:
- how to develop a comprehensive Product Backlog
- competently add value to the Scrum team during the Sprint
- fully understand how Scrum works and their role within the agile environment
With a maximum class size of five people, this seminar is designed to allow participants to dig deep into the role of the Certified Scrum Product Owner. After completing this course, attendees of this seminar will be able to create and manage a Product Backlog, work with a Scrum Team to create high-quality software, and use the Scrum framework to build and deliver the right software. Please refer to our website for a course description and to reserve space for yourself or others on your team. http://www.berteigconsulting.com/CSPOCourseDescription
We look forward to adding value to your team!
If you would like more information contact us at email@example.com
This is my first post on the Agile Advice blog. In fact, it’s my first blog post ever. Before joining the Berteig Consulting team, I had never even heard the words Agile, Scrum, Lean, or OpenAgile. After all, my background is marketing, community relations, and sustainability! Needless to say, I’ve gone through some intense learning about the role of the Growth Facilitator.
The responsibility of the Growth Facilitator is about more than simply prioritizing New Work goals and tasks. I see the role as contributing to the organizational culture, and helping to build the business in a sustainable way. “Sustainability” is an important concept at BCI. It means that we are committed to conducting business in a way that is respectful of the environment, society, and the economy. At the same time, it means that the BCI team operates at a sustainable pace, finding ways to balance our work and life so that we don’t burn out.
As Growth Facilitator, I am also responsible for guiding the team toward delivering greater value for our stakeholders. At Berteig Consulting, our stakeholders don’t just include the company’s owners. Our stakeholders include a wide range of groups, including customers, suppliers, employees, and our families, all without whose support nothing we do would be possible. Delivering value to our stakeholders requires that we keep them in mind when we commit to our tasks each week.
One of the important lessons I learned was to give the team S.M.A.R.T. – Simple, Measureable, Achievable, Relevant, and Timebound – goals and give them space to come up with the tasks to meet the goal. When I first started, I made goals that were broad, saying for example “to take care of our clients” or “to work at a sustainable pace.” Rather than stating goals, I realized that I was making statements of the team’s shared values. And while the team integrated these thoughts into our behavior, it was nonetheless challenging to spin off specific tasks that we could work on. Now, I try to ensure the goals I create conform to a user story format and meet S.M.A.R.T. criteria. For example “Berteig Consulting can update the Certified ScrumMaster course content so that all CSM course participants receive the best value in the market.” As soon as I made the direction clear, the team self-organized and generated tasks required to achieve each goal.
Another key lesson of developing the direction for the team was allowing the Team Members time to review the next Cycle’s goals in advance of the Cycle Planning Meeting so that they could provide feedback and seek clarification. This became particularly important when one team member jumped on a business opportunity that created a significant amount of New Work. We simply could not overlook this great opportunity, and we moved it to the top of the New Work priority list and put it in the next Cycle Plan.
Last, I learned that the Growth Facilitator and Process Facilitator have a complimentary relationship that requires frequent consultation. As the Process Facilitator goes about helping the team overcome obstacles, it can become clear that the team needs to address a systemic challenge during one of the upcoming Cycles. The Growth Facilitator then states the need as a Cycle goal in a S.M.A.R.T. format, allows the team time to give feedback, and prioritizes the goal in the New Work list. When the goal is brought to a future Cycle Planning Meeting, the team breaks the goal into tasks and solves the systemic obstacle that the Process Facilitator identified.
These lessons have helped me understand how the Growth Facilitator role extends beyond prioritizing New Work and guiding the team’s value delivery. The role also fosters the culture in which the work gets done – working at a sustainable pace, taking care of our customers, and maintaining unity of vision.
I would love to hear your thoughts about anything I’ve expressed here. Berteig Consulting is a deep-learning environment, and your feedback is invaluable.
David D. Parker
VP Marketing and Sustainability
We are pleased to announce a new seminar: CSPO – Certified Scrum Product Owner. We have found in our coaching assignments with our various customers that they were struggling to find qualified and well trained Product Owners. Therefore we are offering this new seminar. During this seminar we will train the participant how to do the fundamental tasks of the Product Owner in the Scrum environment. The attendees will learn how to develop a comprehensive Product Backlog, competently add value to the Scrum team during the Sprint, fully understand how Scrum works and their role within it. With a maximum class size of five people, this seminar is designed to allow participants to dig deep into the role of the Product Owner. The first day will be an introduction to Scrum slanted towards the role of the Product Owner. The second day will be an in-depth look at this role. Our first CSPO seminar will take place soon. Please refer to our website http://www.berteigconsulting.com/CSPOCourseDescription to reserve space for yourself or others on your team.
We look forward to adding value to your team!
Upcoming Certified Scrum Product Owner training seminars:
April 23 – 24, 2009 in Newmarket (Berteig Consulting Office)
June 25 – 26, 2009 in Newmarket (Berteig Consulting Office)
July 23 – 24, 2009 in Newmarket (Berteig Consulting Office)
August 20 – 21, 2009 in Newmarket (Berteig Consulting Office)
September 17 – 18, 2009 in Newmarket (Berteig Consulting Office)
If you would like more information contact us at firstname.lastname@example.org
The Definition of “Done” is an important concept that helps us understand how to produce working, potentially shippable software at the end of every Sprint. Previously, I wrote about how to expand the definition of “done” from the perspective of the team’s skills, capabilities and work processes. This time around, let’s look at it from a more tactical perspective: how do we identify things that should be added to the definition of “done” and when do we do this?
Identify Repeating Tasks
Early on, the team will make tasks that include every activity that is done to make software out of the features listed in the Product Backlog. This will include all sorts of things including “Build login web service”, “Write unit tests”, “Review code”, etc. Most of these tasks will be thought of in terms of who will be doing them so that throughout the Sprint every person on the team is busy with tasks and there is very little passing of a single task from one person to another. In other words, one task = one person.
It will quickly become clear that there are a number of similar or identical tasks that show up for most items in the Product Backlog. If you have to develop a user-visible feature or function in the software, you always need to check code into your version control system, you always need to do some sort of testing on the code, etc. So you might have tasks in the Sprint Backlog called “Internationalize login panel”, “Internationalize registration panel”, “Internationalize login error panel”, and so on. Every Product Backlog Item has an “Internationalize ….” task. These tasks can be abstracted and the “Internationalize” idea becomes part of the Definition of Done (DoD). It applies for every Product Backlog Item.
You might also have common pairs of tasks where one of the pair is unique to what is being built, and another is attached to it, but common across many pieces of the system. For example, you might have a task “AnonymousUser class” and an associated “Unit test AnonymousUser class”. Then you might have another task “LoginErrorHandler class” and an associated task “Unit test LoginErrorHandler class”. Again, the idea of unit testing then can be identified as part of the DoD. These apply to every Sprint Backlog Task.
Once these required activities or constraints are added to the DoD, you can then stop identifying them as separate tasks. Instead, they get represented in some other way in your work environment: a checklist on a whiteboard, columns in a spreadsheet, or checkboxes pre-printed on the cards you use to write Tasks or Product Backlog Items.
Prepare for Release
The software might need many things done to it or around it to prepare for a release. Often, these things will be put on the Product Backlog as non-functional business requirements. For example, it may be important to write online help for the system and this is not currently being done by the team. The Product Owner identifies that users will need this help and puts it on the Product Backlog. Yo(1) discovers that These things can eventually be moved into the DoD. For example, yo puts “Online Help” in the Product Backlog and prioritizes it somewhere near to the point in the Product Backlog when the system will be ready for a release. The team eventually gets to this item and does it during a Sprint. At this point, the system is “caught up”, but in order to prepare for the next release, the Product Owner will have to put the same “Online Help” item on the Product Backlog again. Instead of doing this, it can be added to the DoD.
It is critical that the team agree to add these things to the DoD, and not be forced by someone. If the team does not feel that it is within their capacity to include something in the DoD, the ScrumMaster should find ways to assist with this: training, etc. Once something is added to the DoD, it must be completed every Sprint in order to have a successful Sprint.
Release/Deploy to Users
There is nothing like actually getting software into the hands of users to find out what “done” really means! Similarly to preparing for a release by adding things to the Product Backlog, the team may have a “release sprint” or a “stabilization sprint”. Everything that is done in one of these special Sprints could and probably should be added to the DoD sooner rather than later! Again, the team must agree to doing this expansion of the DoD and be supported by the organization so that they have the capacity to meet the DoD every Sprint.