Download - Agile Checklist
AN OVERVIEW OF CEREMONIES, ROLES, ARTIFACTS, AND INFORMATION RADIATORS FOR EXTENDING AGILE ACROSS ORGANIZATIONS
Jack, Joshua (Non-Employee)
12/31/2014
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
1
INTRODUCTION Ken Schwaber and Jeff Sutherland have been known to say, “Scrum is lightweight, simple to understand (but) extremely difficult to master.” What does this mean and why does it sting so much? Well, agile or scrum (more on the distinction in a moment) is an empirical process, meaning that as one (or an organization) learns what works and what doesn’t, those new ideas, concepts, and guidelines get implemented as long as they do not defy the basic “rules” of scrum. Knowing that, it is very difficult to do scrum right, because there is no affirmative “right” way to do scrum! Agile becomes a way of life and a cultural phenomenon rather than a scripted and prescriptive process like some of its heavyweight distant cousins. Because of this mastery or scrum or agile means that an organization has changed the way they work in order to adopt the ability the respond to constant change; patterns are not things that are just done because it has always been that way, but rather are analyzed regularly to understand if they still add value to the organization.
Let’s assume that agile works well and is working well on an individual team. Let’s even assume that the team has some concept of mastery of the basic guidelines and rules of scrum. How do we, then, increase the effectiveness of an agile culture in organizations? Scrum is meant to reduce the amount of administrative overhead and increase team productivity, so what if we applied these same principles across the enterprise? What if organizations “planned together” instead of in silos? How can we take the basic tenets of scrum and scale?
The following is just one idea created out of the research of multiple theories, processes, methodologies, etc. in order to develop a streamlined, scalable set of guidelines. The hope is that they will push the evolution of agile a micro-step and provide another stepping stone to work better and smarter.
WHAT CAN I EXPECT?
AN OVERVIEW OF CEREMONIES, ROLES, ARTIFACTS, AND INFORMATION RADIATORS FOR EXTENDING AGILE ACROSS ORGANIZATIONS
SIMPLIFIED AGILE SCALING FRAMEWORK
CEREMONIES OVERVIEW
ROLES OVERVIEW
INFORMATION RADIATORS
What is Rocket61? Stay tuned for more, but the sneak peak is a concept of improvement. Just take the idea of a rocket. Putting millions of horsepower behind a streamlined vehicle made to take us somewhere and explore new ideas! The 61 is still a secret, but know this, Rocket61 is exploratory, investigative, curious, and every moving.
WHAT IS THE DIFFERENCE BETWEEN AGILE AND
SCRUM? WHY DOES IT SEEM THAT THE
AUTHOR USED THEM INTERCHANGEABLY?
AGILE IS A CULTURAL CONCEPT BACKED BY THE
AGILE MANIFESTO AND THE PRINCIPLES BEHIND
THE AGILE MANIFESTO. THE AUTHOR OF THIS
DOCUMENT WILL USE THE WORD AGILE WHEN
HE FEELS THAT THE THEME BEING DISCUSSED IS
MORE CULTURAL. WITH 72% OF AGILE
ORGANIZATIONS USING SCRUM OR A VARIANT
OF IT, SCRUM IS A WIDELY USED TYPE OF
FRAMEWORK THAT ATTEMPTS TO PUT RULES
AND GUIDELINES AROUND AGILE. THE AUTHOR
WILL USE SCRUM WHEN SPEAKING OF SPECIFIC
RULES THAT ARE USED TO HIGHLIGHT
ORGANIZATIONAL IMPEDIMENTS OR ISSUES TO
ADOPTION OF AN AGILE CULTURE. THEN
AGAIN, THE AUTHOR MIGHT JUST DO
WHATEVER HE WANTS AND USE THEM
INTERCHANGEABLY.
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
SIMPLIFIED AGILE SCALING FRAMEWORK
Simplified Agile Scaling
Team
/Pro
ject
Po
rtfo
lioP
rod
uct
/Pro
gram
http://files.softicons.com/download/transport-icons/standard-road-icons-by-aha-soft/png/256x256/roadmap.pngFunctionality
Release
Architecture
Team BacklogTeamScrumMaster
ProductOwner
Sprint Sprint Sprint
Team Backlog
Sprint Sprint Sprint Sprint
Sprint Sprint
Sprint Sprint Sprint
HardeningRefactoringTech Debt/Bugs
User Stories in Sprints
Hardening Hardening
Portfolio Management
Portfolio Backlog
Marketing
Product Backlog
Release Planning
Business Initiatives
Enterprise Architecture Initiatives
Core Architecture
Interoperability Accessibility
Analysis
Stakeholder(Customer)
Roadmap
Emerging Architecture Emerging Architecture
Approve
Submit
ReviewBusiness Sponsor
Chief ScrumMaster
Chief Product Owner
Release Manager
Development Manager
Based on Scaled Agile Framework. For more information on SAFe, please visit scaledagileframework.com
Release
PSIShippableIncrement
Release
Continuous Gathering of Requirements Continuous Gathering of Requirements
Estimate
Sprint Review Estimate
DailyScrum
Retro-Spective
SprintPlanning
Scrum of Scrums
TeamScrumMaster
ProductOwner
Estimate
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
CEREMONIES AND ARTIFACTS WORKING TOGETHER
Team/Project • Ceremonies
•Daily Scrum
•Sprint Review
•Backlog Refinement
•Retrospective
•Sprint Planning
• Artifacts •Sprint Backlog
•Burndown Chart
Product/ Program
• Ceremonies •Release Planning
•Backlog Refinement
•Retrospective
• Artifacts •Product Backlog
•Release Issues Backlog
•Release Burndown Chart
Portfolio
• Ceremonies •Backlog Refinement
• Artifacts •Executive Vision/Vision Board
•Portfolio Backlog
•Product Roadmap
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
4
CEREMONIES OVERVIEW
GENERAL MEETING All meetings follow a common standard. These basic rules not only increase the efficiency of the meetings but also make them more satisfying for all participants.
RELEASE PLANNING Product Owners, teams, ScrumMasters, and stakeholders come together to provide executive vision, plan the releases over the next time period, and plan the complexity of cross-team collaboration.
ESTIMATION SESSION Product Owner and team work on the estimation of the entire Product Backlog providing the basis for Release and Sprint Planning.
SPRINT PLANNING, PART 1 The team and the Product Owner define the Sprint Goal and the Selected Product Backlog based on the effort estimation as well as business priority
SPRINT PLANNING, PART 2 In Sprint Planning, part 2 the team works on the Selected Product Backlog by adding tasks to each Backlog Item. The effort of each task should not be bigger than one day.
DAILY SCRUM The Daily Scrum helps the team to organize itself. It is a synchronization meeting between the team members. It takes place every day at the same time, at the same place. The meeting is time-boxed to 15 minutes.
SPRINT REVIEW The status of the project is controlled by reviewing the working functionality. The Product Owner decides if the delivered functionality meets the Sprint Goal.
RETROSPECTIVE Inspect and adapt is a fundamental part of Agile. During the Retrospective the team analyzes the previous Sprint to identify success stories and impediments
SCRUM OF SCRUMS Representatives of individual teams synchronize regularly during the sprint to complete the release goal. Issues are identified and information is provided on cross-team collaborative work.
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
5
GENERAL MEETINGS
EVERY MEETING IS TIME-BOXED. THE SCRUMMASTER FACILITATES ALL MEETINGS.
PREPARATION
The meeting has a goal All participants are invited The meeting has a defined timebox The agenda is defined at least one day before the
meeting takes place The meeting goal and agenda has been sent to all
participants All resources are booked
Suitable Room for the desired discussions/actions Projector or connected large screen monitor of some kind Laptop or other internet-connected device capable of connecting to the projector/screen Flip chart and markers (optional)
The meeting room is fully prepared before the meeting starts
FACILITATION
A PARKING LOT IS A LIST ON A FLIP CHART TO COLLECT TOPICS
WHICH ARE NOT PART OF THE MEETING AGENDA
Present the meeting goal
Present the agenda
If a discussion about a topic starts that is not part of the
agenda:
Add the topic to the parking lot
If the meeting time is over but the goal has not been
reached:
Arrange a new meeting
If the participants achieve results:
Write the results down on the flip chart
Make sure everyone agrees about the written results
If the parking lot is not empty:
Find a person responsible for each topic
Add the name of the person in charge to each topic
MANY MEETINGS CAN BE AVOIDED BY QUICK CONVERSATIONS BETWEEN TEAM MEMBERS!
OUTPUT
Every participant knows where to find
the results
HOW TO HAVE BETTER MEETINGS:
HOW TO RUN YOUR MEETINGS LIKE APPLE AND
GOOGLE, BY SEAN BLANDA
11 SIMPLE TIPS FOR HAVING GREAT MEETINGS
FROM SOME OF THE WORLD’S MOST PRODUCT
PEOPLE, BY CAMILLE SWEENEY AND JOSH
GOSFIELD, FASTCOMPANY
WHAT UNPRODUCTIVE MEETINGS ARE COSTING
YOU, BY LAURA MONTINI, INC. MAGAZINE
MEETING TICKER WEB APP, BY TOBY TRIPP
MEETINGS ARE A SKILL YOU CAN MASTER, AND
STEVE JOBS TAUGHT ME HOW, BY KEN SEGALL
ROCKET TIP
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
6
RELEASE PLANNING
THE PURPOSE OF RELEASE PLANNING IS TO COMMIT TO A PLAN FOR DELIVERING AN INCREMENT OF PRODUCT VALUE.
PREPARATION
Follow the General Meetings guidelines
Participants are invited:
Product Owner
ScrumMaster
All team members
Stakeholders
Timeboxed to one day (8 hours) per quarter of planning
Executive Vision/Product Board and preliminary road-
map are ready
ScrumMaster validates:
Organization Readiness - aligned strategy for programs and features (scope/roadmap) between product
and business
Content Readiness - vision and context are clear and that the right people are available. Product and
executive teams are ready to present vision and “top ten.” All teams are ready to discuss architectural
and technology impacts
Additional Facilities
Room large enough to allow for collaboration between team members and stakeholders with areas for
breakout sessions
Whiteboards with markers – enough for multi-breakout sessions and teams to interact
Projector
Device capable of accessing and displaying an in-process and finalized product backlog
Remote video conferencing capability
FACILITATION ScrumMaster provides high level overview of the agenda including review of meeting guidelines.
Executives or product owners present
Prioritized roadmap of features, initiatives, epics, etc.
End date of the release cycle
Question & Answer sessions or breakouts focused on architectural or technology challenges as well as any
newly identified dependencies
Teams provide total capacity based on historical data, taking into account any movement or changes (should
be minimal) between teams
Teams work with each other to develop draft plans. These include any newly decomposed user stories
enough to estimate and prioritize further with product owners. Identify, discuss, and plan for cross-team
dependencies
Add any issues to a Release Issues Backlog
OUTPUT
Plan and commit to a set of initiatives and goals for the next release timebox (preferably quarter or half-year)
Teams, ScrumMasters, and Product Owners understand product backlog and issues backlog
Cross-team plan for accomplishing the product backlog
THE AGILE COMMUNITY HAS SEVERAL GOOD
RESOURCES AVAILABLE THAT EXPLAIN RELEASE
PLANNING. MITCH LACEY'S “STRUCTURED APPROACH
TO RELEASE PLANNING” ASSUMES THAT AN
ESTIMATED AND ORDERED BACKLOG EXISTS AND
THAT THE TEAM KNOWS ITS VELOCITY. TOMMY
NORMAN'S “AGILE RELEASE PLANNING 101” GOES A
LITTLE DEEPER INTO THE STEPS LEADING UP TO AND
INCLUDING RELEASE PLANNING.
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
7
ESTIMATION SESSION
THE SIZES OF THE NEXT RELEVANT PRODUCT BACKLOG ITEMS ARE ESTIMATED.
PREPARATION
Follow the General Meetings guidelines
Participants are invited:
Product Owner
Scrum Master
All team members
Timeboxed to 4 hours for a 4 week sprint and relative for
shorter sprints
Product Backlog is prioritized
Product Backlog is visible and accessible to everyone in the meeting
A set of cards for Planning Poker (available from Mountain Goat) for each team member is at hand
(Optional) Planning Poker Apps. Suggestions (all are free):
iOS - Agile Poker Lite or Radtac Agile Tools
Android – Radtac Agile Tools or Scrum Poker Cards
Windows Phone – Dilbert Planning Poker
RIM/Blackberry – Planning Poker
(Optional) Online Planning Poker for remote teams – http://www.planningpoker.com
FACILITATION
Present the goal of the meeting
The Product Owner presents the portion of the Product Backlog that he wants to be estimated
If the Backlog is not estimated at all:
Select a Backlog Item that you expect to be one of the smallest stories you’ll work on, give it 2 story points
For each Backlog Item in the Product Backlog:
The Product Owner explains the story behind the Backlog Item
Each team member selects one of his Planning Poker Cards to vote for the relative size of the Backlog Item
The team members show their cards at the same time
If the estimates differ, the most contrary team members discuss their view of the Backlog Item and the
voting is repeated up to 2 times until all team members share the same opinion the estimate is added to
the Backlog Item
End the Estimation Meeting with a wrap-up
If necessary, schedule an additional estimation meeting
OUTPUT
The estimated Product Backlog is available for everyone in the organization
AS NEW REQUIREMENTS OR DESIGN IS
IDENTIFIED, IT MIGHT BECOME BENEFICIAL TO
REPEAT THE ESTIMATION SESSION DURING
EACH SPRINT. ALSO, SOME TEAMS HAVE FOUND
THAT FULL TEAM ESTIMATION IS NOT ALWAYS
POSSIBLE UP FRONT AND THAT ABOUT 10% OF
THE SPRINT TIME SHOULD BE SPENT
“GROOMING” OR ESTIMATING THE BACKLOG.
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
8
SPRINT PLANNING, PART 1
DEFINE THE SPRINT GOAL AND THE SELECTED PRODUCT BACKLOG.
PREPARATION
Follow the General Meetings Guidelines
Participants are invited:
Product Owner
Scrum Master
All team members
Timeboxed to 4 hours for a 4 week sprint and relative for shorter sprints
Product Backlog is prioritized
Backlog Items are estimated
Product Backlog is visible and accessible to everyone in the meeting
Planned absences of team members are known
The results of the Sprint Review and the Retrospective are available
EVERY APPOINTMENT FOR THE REGULAR SCRUM MEETINGS IS DEFINED AT SPRINT PLANNING. RECOMMENDED DURATION FOR REGULAR SCRUM MEETINGS OF A 30 DAY SPRINT (OR 4 WEEK):
Sprint Planning, Part 1 4 hours Sprint Review 2 hours
Sprint Planning, Part 2 4 hours Retrospective 2 hours
Daily Scrum 15 minutes Backlog Grooming/Estimation 4 hours
FACILITATION
Make the Sprint Schedule visible to everyone
Appointment for the Sprint Planning, parts 1 & 2
First and last days of the Sprint are defined
Appointment for the Daily Scrum Meeting
Appointment for the Sprint Review Ceremony
Appointment for the Retrospective Ceremony
Appointment for the Backlog Grooming Meeting (optional)
Make the Sprint Review Meeting results visible to everyone
Make the Retrospective results visible to everyone
The Product Owner informs team about the product vision and sprint goal(s)
The Product Owner reviews the top estimated and prioritized backlog items
The Product Owner and the team mutually agree on the Sprint Goal and the Selected Product Backlog based
on team capacity.
OUTPUT
Team understand the sprint timeline
Selected Product Backlog is well prepared for Sprint Planning, Part 2
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
9
SPRINT PLANNING, PART 2
DEFINE TASKS TO CREATE THE SPRINT BACKLOG AND COMMIT TO THE SPRINT GOAL.
PREPARATION
Follow the General Meetings Guidelines
Participants are invited:
Product Owner
ScrumMaster
All Team members
Timeboxed to 4 hours for a 4 week sprint and relative for shorter sprints
The Selected Product Backlog is accessible for the task planning
Means to create and track tasks (software or physical task board)
FACILITATION Team members define tasks for each Backlog Item
Make sure that every piece of work (as much as can be known) is taken into account:
Coding
Testing
Code review
Meetings
Learning new technologies
Writing documentation
If a task effort is bigger than one to two days:
Try to split the task into smaller tasks
If the team believes that the Sprint Backlog is too large:
Remove Backlog Items together with the Product Owner
If the team believes that the Sprint Backlog is too small
Move the most important Backlog Items from the Product Backlog to the Sprint Backlog together with the
Product Owner
The team commits to the Sprint Goal
OUTPUT
Sprint Goal and Sprint Backlog are
visible to everyone in the
organization
The tasks in the Sprint Backlog are
accessible to all team members
Select Sprint Goal Analyze and Evaluate Product Backlog
SPRINT PRIORITIZATION
Commit to the sprint goal Create sprint backlog by creating and estimating tasks Review and commit capacity
SPRINT PLANNING
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
10
DAILY SCRUM
THE MEETING IS TIME-BOXED TO 15 MINUTES.
PREPARATION
Follow the General Meetings Guidelines
Participants are invited:
All team members
Scrum Master
(Optional) Product Owner
(Optional) Other stakeholder
Timeboxed to 15 minutes
Team members have updated their tasks on the virtual or physical
team board
Issues backlog is available to add, remove, or edit items
FACILITATION
Every team member answers the three questions.
What did you accomplish yesterday?
What are your plans for today (or what are you working on today)?
Do you have any issues or impediments that might keep you from
accomplishing your plans for today?
If something is in the way: add it as an issue to the Issue Backlog
If a discussion starts:
Remind the team members to focus on answering the questions
If a stakeholder wants to say something: remind him politely, that this meeting is only for the team
OUTPUT Issues Backlog is updated
Team knows if there is something from the previous day that is an issue to another team member.
Team is aware of what the rest of the team is planning to do and if they are needed to assist.
THERE ARE ADDITIONAL WAYS TO
CONDUCT A DAILY STAND UP.
ALTERNATIVES ARE CONCEPTS LIKE
“WALKIN HE OARD,” ETC. ASK
A OU OUR “FUN WI H DAILY
RUM ” RAININ !
ROCKET TIP
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
1 1
SPRINT REVIEW
REVIEW ALL BACKLOG ITEMS THE TEAM HAS DELIVERED IN THIS SPRINT AND CHECK IF THE SPRINT GOAL WAS ACHIEVED.
PREPARATION
Follow the General Meeting Guidelines
Participants are invited:
Product Owner
Scrum Master
All team members
Stakeholders
Customers
Other team members
Timeboxed to 2 hours (or shorter for shorter sprints)
The Sprint Goal is visible to everyone
The Selected Product Backlog is accessible and visible to everyone
The team has prepared workstations, devices etc. to demonstrate the new functionality
FACILITATION The team presents the Sprint results and demonstrates the new functionality, Backlog Item after Backlog Item
If the Product Owner wants to change a feature:
Add a new Backlog Item to the Product Backlog
If a new idea for a feature occurs:
Add a new Backlog Item to the Product Backlog
If the team reports an issue which is not solved yet:
Add the issue to the Issue Backlog
OUTPUT Common understanding about the Sprint results and the product state
DILBERT DEMONSTRATES HOW NOT TO DO A SPRINT REVIEW
THE SPRINT REVIEW
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
12
RETROSPECTIVE
LEARN FROM PAST EXPERIENCE TO IMPROVE THE PRODUCTIVITY OF THE TEAM.
PREPARATION
Follow General Meetings Guidelines
Participants are invited:
Scrum Master
All team members
(Optional) Product Owner
Timeboxed to 2 hours
Additional facilities:
paper products large enough to capture information with markers (optional)
a white board and markers to perform exercises (optional)
Projector
device capable of capturing and presenting information through the projector
PRIME DIRECTIVE: REGARDLESS OF WHAT WE DISCOVER, WE MUST UNDERSTAND THAT EVERYONE DID THE BEST JOB
HE OR SHE COULD, GIVEN WHAT WAS KNOWN AT THE TIME, HIS OR HER SKILLS AND ABILITIES, THE RESOURCES
AVAILABLE, AND THE SITUATION AT HAND.
FACILITATION
Present the goal of the meeting
Present the Prime Directive
Discuss and answer the questions:
What went well?
What didn’t go well?
What can we do better next sprint?
Identify who is responsible for the answers to “what can we do better next sprint?”
Prioritize the list of improvements
Run a wrap-up of the meeting:
Each participant gives a short reflection about the retrospective
OUTPUT
Any issues are added to the Issues Backlog
“What can we do better next sprint” is added to Team Working Agreement
Week 1 Week 2 Week 3
THERE ARE A NUMBER OF ACTIVITIES THAT CAN BE
PERFORMED DURING THE RETROSPECTIVE. THESE
CAN BE TIMELINES, STARS, CONTROL MATRIX, AND
SAFETY CHECK SPEEDBOAT/SAILBOAT ALL IN
ADDITION TO THE TRADITIONAL QUESTIONS.
HE K OU OUR “EFFE IVE RE RO E IVE”
TRAINING SESSION!
FIG. STARFISH EXERCISE FIG. EMOTIONAL TIMELINE EXERCISE
Milestone Milestone Milestone
Milestone Milestone
Milestone Issue
Issue Issue Issue
Milestone
Milestone Failure
Failure
ROCKET TIP
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
13
SCRUM OF SCRUMS
SCALING AGILE TO THE ENTERPRISE REQUIRES NEW WAYS OF THINKING. SCRUM OF SCRUMS PROVIDES A WAY OF
CROSS-TEAM COLLABORATION WITHOUT CREATING MANAGEMENT OVERHEAD.
PREPARATION
Follow the General Meetings Guidelines
Participants are invited:
Representatives of each of the teams that share common backlog
elements or programs
Scrum Masters
(Optional) Product Owners
Chief Scrum Master
(Optional) Chief Product Owner
Timeboxed to 15 minutes; scheduled for at least once per week
Issues backlog is available to add, remove, or edit items
FACILITATION
Every team representative answers the three questions.
What did your team accomplish since the last Scrum of Scrums?
What are your plans until the next Scrum of Scrums (or what are you
working on now)?
Do you have any cross-team issues or impediments that might keep you
from accomplishing your plans?
If something is in the way: add it as an issue to the Issue Backlog
If a discussion starts:
Remind the team representatives to focus on answering the questions
OUTPUT
Release Issues Backlog is updated
Team representative and Scrum Master know if there is something from the previous time period that is an
issue to another team.
Team representative and Scrum Master is aware of what the rest of the teams are planning to do and if their
teams are needed to assist.
WHILE THE SCRUM OF
SCRUMS IS NOT A
TRADITIONAL SCRUM OR
AGILE CEREMONY, IT ADDS
VALUE TO ORGANIZATIONAL
OR ENTERPRISE AGILE
SCALING
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
14
ROLES OVERVIEW
PRODUCT OWNER The role responsible for the success of the release or project. The Product Owner leads the organizational effort by conveying the vision to the team, outlining the work in the backlog, and prioritizing it based on value.
SCRUMMASTER Acts as a facilitator for both the team and the Product Owner. The ScrumMaster removes impediments that impact the team’s forward progress toward the sprint goals and manages the scrum/agile process.
TEAM Consists of 3-9 people excluding the Product Owner and ScrumMaster (some variants say 7 +/-2). The team is comprised of individuals who, as a whole, are capable of carrying out the sprint goals. They are autonomous and work together in the same general area.
STAKEHOLDER An individual or group of individuals (such as a department or component-based group) that can affect the outcome of the sprint or project. Generally, this role is managed outside of the scrum/agile process by the Product Owner, but can impact the success of the initiative.
CHIEF SCRUMMASTER Acts a leading driver or innovator in the areas of operational agile/scrum within an organization. This role will sometimes act as the ScrumMaster of ScrumMasters or have additional responsibilities of program or portfolio management.
CHIEF PRODUCT OWNER The single point of accountability (single ringable neck) for the success or failure of the complete program or product line. This role is responsible for the entirety of the roadmap or enterprise product backlog.
Serve as the Agile expert by
facilitating and coaching
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
15
PRODUCT OWNER KEY QUALITIES AND
CHARACTERISTICS
Availability Business Savvy
Communicative Experienced
Humble Empowered
Prepared Fun
Collaborative Flexible
Historically Knowledgeable
PRODUCT OWNER
IN AGILE, THE PRODUCT OWNER IS THE ONLY ONE WITH ORGANIZATIONAL AUTHORITY. THIS AUTHORITY IS USED TO
PAVE THE WAY FOR THE TEAM TO BE ABLE TO COMPLETE THE VISION.
RESPONSIBILITIES
PEOPLE
Representative of all stakeholders
Understands users and customers
Creates common communication
between the team and the
stakeholders
STRATEGY
Focus is on the business model
Carries the product vision to the team
PRODUCT DELIVERY
Formalizes a specific, measurable and reasonable Product Backlog and prioritizes it by business value
Maintains the Product Backlog continuously
Tracks time and budget (project progress)
Validates the completed sprint backlog and the sprint goal
ARTIFACTS
Product Vision
Product Backlog
Release Burndown
Product Roadmap
AUTHORITY Decides on delivery dates
Can cancel a sprint if it no longer meets business value
Because he/she maintains the Product Backlog, the
Product Owner can request what work is done in a
sprint.
LIMITATIONS
Cannot determine the amount of work that a team performs in a sprint
Cannot change the Sprint Backlog unless an emergency arises
Although they have organization authority, the product owner should not tell the team how to deliver a solution.
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
16
SCRUMMASTER KEY QUALITIES AND
CHARACTERISTICS
Servant-Leader Facilitative
Communicative Assertive
Enthusiastic Transparent
Accountable Empowering
Conflict Resolver Flexible
Situationally Aware
I.N.V.E.S.T.
INDEPEN-DENT
NEGOTIABLE
VALUABLE
ESTIMABLE
SMALL
SCRUMMASTER
THE SCRUMMASTER IS RESPONSIBLE FOR MAKING SURE A TEAM OPERATES BY AGILE PRINCIPLES AND PRACTICES
(PROCESS OWNER). THE SCRUMMASTER IS OFTEN CALLED A COACH FOR THE TEAM, HELPING THE TEAM DO THE BEST
WORK IT POSSIBLY CAN.
RESPONSIBILITIES
PEOPLE
Coach and facilitator for the team and the product owner
Protects the team from outside distractions
Protects the team from over-commitment as well as complacency
STRATEGY
Always has a training plan for the team – the Issues Backlog
Acts as “process owner” for the team, making sure the team not only lives by the values of agile, but also
investigates new ways of working better
Works with the organization and other ScrumMasters
to implement agile practices outside of the
development teams
PRODUCT DELIVERY
Improves productivity by removing issues that impair
the teams ultimate goal – delivering a potentially
shippable increment
Works with the product owner to forecast team
velocity
Validates the manageability of the product backlog by
making sure items near the top are expressed as I.N.V.E.S.T. user stories (see call out box below)
ARTIFACTS
Sprint Backlog
Sprint Burndown Chart
Taskboard
AUTHORITY
The ScrumMaster has authority over the process. He or she is the one responsible for making sure that the agile principles are followed
Protects the team and works with the Product
Owner to maximize the return on investment
Has authority within the team to question
ways of working
Works with other ScrumMasters to implement
organizational agile improvement
LIMITATIONS
Servant-Leader, no organization authority whatsoever Team does not report to ScrumMaster FIG. ARE YOUR STORIES GOOD ENOUGH?
TESTABLE
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
17
TEAM KEY QUALITIES AND CHARACTERISTICS
Cross-Functional Collaborative
Learning Multidisciplinary
Enthusiastic Transparent
Autonomous Discipline
Responsibility Initiative
Courage to Seek Out Review
TEAM
TO WORK EFFECTIVELY, IT IS IMPORTANT TO THE TEAM THAT EVERONE FOLLOWS A COMMON GOAL, ADHERES TO THE
AME “WAY OF WORKIN ,” AND HOW RE E T TO ONE ANOTHER.
RESPONSIBILITIES
PEOPLE
Team is responsible for the work and culture. Issues with other team members should be handled internally
first
Self-Managing and Self-Organizing – empowered to define who will perform the tasks and in which order
they are performed
Update each other on what they are doing and if there are any issues, not just during the Daily Scrum
Work with and negotiate with the Product Owner, who is the primary client
STRATEGY
Must continuously improve the ways of working in order to increase efficiency and consistency
Breakdown the requirements, create tasks, and estimate work items.
PRODUCT DELIVERY
Responsible to deliver the committed sprint backlog within the required quality metric
Responsible for not only the delivery of the sprint goal and backlog, but also negotiating both of those
artifacts
All sprints must have a potentially shippable increment
ARTIFACTS
Sprint Goal
Sprint Backlog
Team Agreement
AUTHORITY Team defines how much work they can undertake based on past sprint capacity Autonomy on the technical solution for the functionality requested Able to define improvements to systems and methods in order to increase quality and efficiency Team defines the way they will work and sets rules of engagement (within reason)
LIMITATIONS
The team does everything to win the game – to deliver
the product
Cross-functional - the full know-how to realize the
product
Understands the vision and Sprint Goals of the Product
Owner in order to deliver potentially shippable product
increments
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
18
Emergency? Yes
NoUser Story reviewed Team agrees to swap sprint
item for new story
User Story is createdor updated
Lower priority user storyis identified in current sprint to
swap with the new story.
Stakeholder submits newissue to Product Owner
User Story CompletedUser story placed
in product backlogUser story worked in
priority order
Secondary Workflow
STAKEHOLDERS
STAKEHOLDERS ARE PARTIES WITH AN INTEREST IN THE PRODUCT BEING DEVELOPED AND/OR THE AGILE PROCESS.
THEY MIGHT INCLUDE VENDORS, CUSTOMERS, BUSINESS OWNERS, SUBJECT MATTER EXPERTS, SUPPORT, OR OTHER
INTERNAL ORGANIZATIONS.
RESPONSIBILITIES
PEOPLE
Engage through interest in the
outcome and process during a project or
product release cycle
STRATEGY
Work with the chief product owner and
chief scrummaster in identifying
business and architectural initiatives
PRODUCT DELIVERY
Support the team, product owner, and
scrummaster in the delivery and
execution of a project or product
Provides valuable feedback
throughout the sprint and release relative to their involvement in the backlog items
ARTIFACTS
Product Feedback
AUTHORITY
Because a stakeholder could be a resource manager, it is important to recognize that these roles, albeit indirectly, still need to be managed
Ability to fund or not to fund, in several scenarios, the ongoing development of work Can be a remover of issues and roadblocks
LIMITATIONS
Will work through the product owner for adding or changing work in the product backlog Should not directly manage the day to day activities of the team
Keep Satisfied Manage Closely
Monitor Keep Informed
Po
we
r
Interest
Levels of Interest and Power
Low power, less interested people: again, monitor these people, but do not bore them with excessive communication.
Low power, interested people: keep these people adequately informed, and talk to them to ensure that no major issues are arising. These people can often be very
helpful with the detail of your project.
High power, less interested people: put enough work in with these people to keep them satisfied, but not so much that they become bored with your message.
High power, interested people: these are the people you must fully engage and make the greatest efforts to satisfy.
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
19
CHIEF SCRUMMASTER
A LEADING DRIVER FOCUSED ON COACHING AND ORGANIZING SCRUMMASTERS, SUPPORTING THE ENTERPRISE OR
ORGANIZATIONAL IMPLEMENTATION OF AGILE OR SCRUM, AND COACHING MANAGEMENT WITHIN THE PORTFOLIO
BACKLOG.
RESPONSIBILITIES
PEOPLE
Acts as Product Owner to the ScrumMasters, helping define the organizational direction for process based
on the needs of the customer (organization)
Acts as a ScrumMaster to the organizational leadership, portfolio team, and executive team
Researches and shares resources for teams and programs to successfully execute the roadmap
STRATEGY
Serves as coach, advisor, and agile counselor to the organization
Participates in developing business, development, and enterprise process in order to align with the Agile
Manifesto and Principles behind the Agile Manifesto
Works with Product Owners, customers (business owners) and other managers to maintain alignment with
strategic vision
PRODUCT DELIVERY
Coaches enterprise teams and helps foster improving agile project, program, and portfolio management
Participates in and, more than likely, facilitates release planning
Participates in and, more than likely, facilitates scrum of scrums
Removes organizational issues
Coaches the Chief Product Owner on improving the Portfolio Backlog
ARTIFACTS
Organizational Issues Backlog
Agile Adherence Checklists
Portfolio Backlog
AUTHORITY
Generally, has organizational leadership of the ScrumMasters through an Agile Office Owns the enterprise or organization process Can direct and suggest process changes across the enterprise to facilitate improvements in efficiency
LIMITATIONS
As still a ScrumMaster, the Chief ScrumMaster only has authority within the group to which he is coaching and
only that allowed
ScrumMaster
Chief ScrumMaster
Acts as “Agent of Change”
Keeps pushing process improvements
Challenges existing behaviors
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
SAMPLE CHIEF SCRUMMASTER OPERATIONAL OVERSIGHT
Agile 3POAgile Project, Program, and
Portfolio Office
Project Management
The discipline of planning, organizing and motivating resources to achieve project success
StrategyEstablishing a roadmap for continued and improving
project success
ProcessDocument and improve guidelines for successful
project management
Project Portfolio
ManagementThe scope necessary to have
successful project implementation
MethodologyEvolving in the way we
approach the work in order to increase success
GovernanceThe processes that need to
exist for a successful project
ToolsThe devices and methods
used to implement a successful project
Quality IndexIdentifies how the PM is
progressing on the project deliverables
Regular Tool Reviews
Spot check random samples of adherence, from WIT
field compliance to review of team agility
Project ReviewsContinuous feedback loops
and reviews as to PPM adherence
MetricsTracking projects, iterations,
epics, stories, tasks, bugs
Exceptions Review
Review requested exceptions and approve/
deny/approve with mitigation
Team Foundation
ServerManage, oversee, and
implement changes
Project ServerManage, oversee, and
implement changes
SharePointManage, oversee, and
implement changes
Microsoft Project
ProfessionalMaintain, manage, teach
Agile ScalingProvide agile project
management consultation on portfolio team
Release Planning
Represent and facilitate any discussion of portfolio implementation and
readiness.
Scrum MasterAct in the role of scrum
master for the individual scrum/development teams
Program Management
Provide program oversight to groups of projects that
represent key organizational bus iness direction.
Project PlansMaintain project plans for each project. Allows for
forecasting and for identifying areas of risk regarding schedule and
resources.
Project Plan Templates
Continual improvement of project plan templates to fit
evolving process improvement.
Process Initiative List
Handling multiple process improvement projects that
need to be watched.
Heat MapReview and maintain
active process enhancement across
the enterprise
Gold CopiesReview, enhance, and maintain all deliverables and
process gold copies.
Change Management
Incremental and constant improvement in a way that
is consumable.
New ProcessesStrategically implementing
new ways of working to support ever changing needs and standards.
Continued Education
Constant and consistent review of new training
opportunities for both the project office as well as product development.
EnhancementsContinuous improvement regarding agile and scrum
methodologies
TemplatesMaintaining and
improving any project management templates
ImprovementCoach, teach and mentor toward a greater success
Onboarding Training
Providing updated training documentation related to
the latest adaption of Agile at Greenway
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
21
ROCKET SOAPBOX
THIS DOCUMENT REJECTS THE IDEA OF THE
NEED FOR A PRODUCT MANAGER AND
BELIEVES THAT IT IS A HOLDOVER FROM
TRADITIONAL SYSTEMATIC METHODOLOGIES.
THE CONCEPT SEEMS TO CREATE A SCHISM
THAT THE PRODUCT OWNER CONCEPT FIXED,
THAT IS, A DISCONNECT BETWEEN CUSTOMER
AND TEAM. THE VERY IDEA OF A PRODUCT
MANAGER, ACCORDING TO OTHER SCALING
MODELS, IS THAT THE PRODUCT MANAGER IS
EXTERNALLY FACING, WHERE THE PRODUCT
OWNER IS INTERNALLY FACING. THE FOCUS
SHOULD BE AT SCALING OUR TEAMS TO BE
ABLE TO CONTINUE TO INTERFACE WITH THE
CUSTOMER, WITH THAT RELATIONSHIP
FOSTERED AND BOUNDARIED BY THE PRODUCT
OWNER.
CHIEF PRODUCT OWNER
A LARGE AGILE PROJECT CONSISTS OF MANY SMALL TEAMS. EACH TEAM NEEDS A PRODUCT OWNER, BUT EXPERIENCE
SUGGESTS THAT ONE PRODUCT OWNER USUALLY CANNOT LOOK AFTER MORE THAN TWO TEAMS IN A SUSTAINABLE
MANNER. CONSEQUENTLY, WHEN MORE THAN TWO TEAMS ARE REQUIRED, SEVERAL PRODUCT OWNERS HAVE TO
COLLABORATE. WHILE THIS CAN WORK, IT CREATES AN ISSUE WHERE HERE I NO “ INGLE RINGABLE NECK.” THE
SOLUTION IS TO INTRODUCE A CHIEF PRODUCT OWNER.
RESPONSIBILITIES
PEOPLE
Guides the other product owners
Works with one potentially large and complex product,
or acts as the product owner over other product
owners that manage multiple, independent sub
products
Represents an industry or key strategic sector
Facilitates common communication between the
executive teams and the development teams
STRATEGY
Facilitates product decisions
Focuses on the enterprise business model
Carries the executive vision and communicates the
roadmap to the organization
PRODUCT DELIVERY
Responsible for the overall product or program
direction
Manages a portfolio of backlog items and prioritize across products for each sprint or each release
Tracks time and budget (release progress)
Communicates release readiness along with chief ScrumMaster
ARTIFACTS
Vision Board
Release burndown (in conjunction with product owners)
Product roadmap/Portfolio Backlog
AUTHORITY
Decides on release dates Can cancel a release if it no longer meets business value Because he/she maintains the product Backlog, the Chief Product Owner can request what work is done in a
release.
LIMITATIONS
Cannot determine the amount of work that the teams perform in a release Cannot change Sprint Backlogs unless an emergency arises within the release Although he/she has organization authority, the Chief Product Owner should not instruct their team to tell the
development teams how to deliver a solution.
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
22
ARTIFACTS
PRODUCT ROADMAP
A product roadmap is a high-level plan that describes how the product is likely to grow. It allows the organization to express where the product is going, and why it’s worthwhile investing in it. An agile product roadmap also facilitates learning and change. A great way to achieve these objectives is to employ a goal-oriented roadmap – a roadmap based on goals rather than dominated by many features.
PORTFOLIO BACKLOG
The portfolio backlog builds upon the product roadmap and begins to break down the roadmap into features and initiatives that will need to be accomplished in order to meet the business value of the product roadmap. Where the roadmap might focus on key business and architectural initiatives, the portfolio backlog begins focusing on what needs to be done by each product in order to make the roadmap a realization. This becomes the basic estimable building blocks of the release, product, and ultimately, sprint backlogs. While there is no
PRODUCT BACKLOG
The product backlog is a prioritized features list, containing short descriptions of all functionality desired in the product.
It is not necessary to start a project with a lengthy, upfront effort to document all requirements. Typically, a team and
its product owner begin by writing down everything they can think of for backlog prioritization and estimation. This
product backlog is almost always more than enough for a first sprint. The product backlog is then allowed to grow and
change as more is learned about the product and its customers.
SPRINT BACKLOG
The sprint backlog is a list of tasks identified by the team to be completed during the sprint. During sprint planning, the
team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks
necessary to complete each user story. Most teams also estimate how many hours each task will take someone on the
team to complete.
ISSUES BACKLOG Issues occur on all organizational levels. The Issues Backlog (whether team, product/release, or portfolio) identifies,
prioritizes and makes them visible to the organization. Capture and track these issues updating new, in-process, and
closed states. This backlog becomes the learning list for the team and is managed by the ScrumMaster whereas the
release issues and portfolio backlogs are generally managed by the Chief ScrumMaster.
“ O 10” Y I AL I UES
The ceremony rules are not followed
Product Vision and Sprint Goal(s) are unclear
The Product Owner is not available for questions
Backlogs are not prioritized by business value
Not everyone who contributes to the delivery is on the team or program
The ScrumMaster has to perform other tasks and is not able to focus on the team progress
The teams are too big (> 9 members)
The teams have no room where they can work together
The teams have no dashboard to access the Sprint Backlog
Information Radiators are not available to the entire organization
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
23
INFORMATION RADIATORS
RELEASE BURNDOWN
On teams where releases to the customer base are not occurring at the end
of each sprint, the team tracks its progress against a release plan on a
release burndown chart. The release burndown chart is updated at the end
of each sprint by the ScrumMaster. The horizontal axis of the release
burndown chart shows the sprints; the vertical axis shows the amount of
work remaining (effort) at the start of each sprint.
SPRINT BURNDOWN
All teams, whether delivering a potentially shippable increment or an actual
released product, use a sprint burndown chart to track the remaining effort
in product backlog items for the sprint. The horizontal axis of the sprint
burndown chart shows the number of days in the sprint while the vertical
axis shows the amount of work remaining (effort) during each day of the
sprint.
TASK BOARD
The team can make the sprint backlog visible by putting it on a task board.
This task board can be either physical or virtual (managed through any of
the amazing software tools available to the community). Team members
update the task board continuously throughout the sprint; if someone
thinks of a new task (“update the database for the new happy or not
column”), he or she writes a new task and adds it to the task board. Either
during or before the daily scrum, estimates are changed (up or down), and
tasks are moved around the board.
PRODUCT VISION BOARD The Product Vision Board is a tool that can be used to describe and visualize the product vision and strategy. It helps capture and validate ideas about the product, taking into account business drivers, competition, marketability and more. A copy of the Product Vision Board is located on the next page. For the original, please see Roman Pichler’s website outlined in the credit section of this document.
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
24
PRODUCT VISION BOARD TEMPLATE
COMPILED AND DEVELOPED BY JOSHUA A. JACK, CSM, SFC
25
CREDITS Roman Pichler, Pichler Consulting and his Product Vision Board – http://romanpichler.com
Mike Cohn, Mountain Goat Software – http://mountaingoatsoftware.com