scrum right - scrum for enterprise environments

BetcherConsulting.com Robert R. Betcher, PMP, CSM1

PREPARATION

SCRUM PROCESS

SCRUM Right

SCRUM ROLES

•Business case & funding•Contractual agreement•Vision•Initial productbacklog•Initial release plan•Stakeholderbuy-in•Assemble team

•Sprint planning meeting

•Daily Cycle

•Sprint review•Sprint retrospective

•Update Productbacklog

RELEASE•Product increment

•Product owner

•Scrum master

•Team members

•Stakeholders•Users

by

Robert R. Betcher, PMP, CSM & ACP

www.agilemethodology.usAgile and Project Management Resource

Copyright 2013

BetcherConsulting.com Robert R. Betcher, PMP, CSM & ACP2

PREPARATION

SCRUM PROCESS

SCRUM PROCESS

SCRUM ROLES



•Daily Cycle


•Update Productbacklog


•Product owner

•Scrum master

•Team members


3

15-30 DAYS

24 HOURS

15 min. Daily meeting.Team members respond to basics:A.What did you do since last Scrum Meeting?B.Do you have any obstacles?C.What will you do until nest Scrum Meeting?

New functionality

24 hr Scrum

Team BacklogItems expanded by team

Sprint BacklogFeatures assigned to sprint

ProductBacklogPrioritized product features desired by client

SCRUM PROCESS

BetcherConsulting.com Robert R. Betcher, PMP, CSM & ACP

4



•DailyCycle

•Daily Scrum•Daily Work

•Product increment


•Updateproductbacklog

PREPARATION

RELEASESCRUM

PROCESS

SCRUM PROCESS

Product PhaseOrRelease


5

SCRUM ARTEFACTS

PREPARATION

SCRUM PROCESS

SCRUM PROCESS

SCRUM ROLES



•DailyCycle




Complete Artifacts:

BRD’s or Technical RequirementsDiagrams (System, Workflow, DB, UML, Mockups, Wireframes, etc..)BetcherConsulting.com Robert R. Betcher, PMP, CSM & ACP

6

SCRUM ARTEFACTS

PREPARATION

SCRUM PROCESS

SCRUM PROCESS

SCRUM ROLES

•Product owner

•Scrum master

•Team members




•DailyCycle




•Daily Scrum•Daily Work


7

1 - 4 WEEKS

24 H

Sprint Backlog•Features assigned to sprint•Estimated by team•Team Commitment

Product Backlog•Features - prioritized by client Shippable

Product

SCRUM PROCESS


8

1 - 4 WEEKS

24 H

Sprint Backlog•Features assigned to sprint•Estimated by team•Team Commitment

ProductBacklog•Features prioritized by client

Retrospective

SCRUM PROCESS

Review


9

2 WEEKS

24 HOURS

15 min. Daily meeting.Team members respond to basics:A. What did you do yesterday?B. What will you do today?C. Do you have any obstacles or impediments?

New functionality

24 h Scrum

Team BacklogSprint Backlog

Product Backlog

SCRUM PROCESS


10

Task

TaskTask

Task

Task

Task

Task Task

To Do Doing Done

Task

Task

Task

Task

Task

Task

Task

Task

Task

Task

Task

Task

Task

Task

This is an exampletext

SCRUM BOARD (Kanban Board)

Task

OwnerDelivery Date


11

•The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders, and ensuring the value of the work the Development Team does. (This is not a PM and typically is a role held at the Director Level or Higher)

•A cross-functional group of people responsible for delivering potentially shippable increments of Product at the end of every Sprint. Ideally 5 to 7 members. Team Members are considered fully engaged at 5-6 hours a day.

•The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits. (This is not a Project Manager, Project Coordinator or Project Secretary.)

•The stakeholders are the customers, vendors. They are people who enable the project and for whom the project produces the agreed-upon benefit[s] that justify its production. They are only directly involved in the process during the sprint reviews.

•People who control the work environment.

SCRUM Roles

• Product Owner • Development Team • Scrum Master • Stakeholder • Manager


12

•A prioritized list of high-level requirements. (Best Stored in a SCRUM Tool or ERP Solution)

•An epic is a group of related stories, mainly used in product roadmaps and the backlog for features that have not yet been analyzed enough to break down into component stories, which should be done before bringing it into a sprint so to reduce uncertainty. Epics can also be used at a both program and project level.

•A Story is a feature that is added to the backlog and has a specific suggested structure. (Effort is less than a Sprint in Duration – carry over is not a best practice.)•A Spike (Tracer Bullet) is a story or task aimed at answering a question or gathering information, rather than at producing shippable product.

•Added to the story at the beginning of a sprint and broken down into hours. Each task should not exceed 12 hours, but it's common for teams to insist that a task take no more than a day to finish.

• Product/ Sprint Backlog

• Epic • Story or Spike • Task

SCRUM Effort Organization


13

•Relates to an abstract point system assigned during Grooming or Planning Sessions, used to discuss the difficulty of the story, without assigning actual hours. The most common scale used is a rounded Fibonacci sequence (1,2,3,5,8,13,20,40,100), some teams use linear scale (1,2,3,4...), powers of two(1,2,4,8...), and clothes size (XS, S, M, L, XL). Planning Poker

•Added to the story at the beginning of a sprint and broken down into hours. Each task should not exceed 12 hours. Tasks information is typically deduced by teams during the Sprint Planning sessions and should be calculated by those performing the work.

• Story Points • Task Effort

SCRUM Effort Measurements


14

•This is the process of estimating the existing backlog using effort/points, refining the acceptance criteria for individual stories, and breaking larger stories into smaller stories:•Meetings should not be longer than an hour

•At the beginning of the sprint cycle (every 7–30 days), a "Sprint planning meeting" is held:

Select what work is to be done

Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team (Eight-hour time limit )(1st half) Entire team: dialog for prioritizing the Product Backlog

(2nd half) Development Team: hashing out a plan for the Sprint, resulting in the Sprint Backlog

•The Sprint Review Meeting (4 hr Limit):Review the work that was completed and not completed

Present the completed work to the stakeholders

•The Sprint Retrospective (3 hr limit): All team members reflect on the past sprint

Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?

•Each day during the sprint, a project team communication meeting occurs. This is called a daily scrum, or the daily standup. (15 min limit)•Team Members Answer 3 Questions:

What have you done since yesterday?

What are you planning to do today?

Any impediments/stumbling blocks?

•Each day normally after the Daily Scrum•Teams answer 4 questions:

What has your team done since we last met?

What will your team do before we meet again?

Is anything slowing your team down or getting in their way?

Are you about to put something in another team's way?

SCRUM Meetings

• Backlog Grooming • Sprint Planning• Task Planning

• Sprint Review• Sprint Retrospective

• Daily SCRUM • SCRUM of SCRUMS


15

Sprint Burn downMethod to Track the Team’s

Progress.

Charts

Team Behind Schedule

Team Ahead of Schedule


16

Sprint Burn UpMethod to Track

Story Points Added to a Sprint or Backlog

CHEVRON DIAGRAM

Scope Added To Backlog


17

Capacity PlanningMethod to Track the Team’s

Utilization during Task Planning.

Charts

Team Member Name 1

Team Member Name 2

Team Member Name 3

Team Member Name 4

Team Member Name 5

Team Member Name 6

Team Member Name 7

Team Member Name 8

Team Member Name 9


COMPANY NAME NAME OF PRESENTER18Robert R. Betcher, PMP, CSM & ACP

Working toward a self-managing team

TEAM THE MOST IMPORTANT COMPONENT

Team BuildingWhat is and what is not Team Building.

Team Member PersonalitiesThe many personalities that make up a Team.

Well Formed TeamsWhat are the characteristics of well formed and mal formed teams.

ProductivityWhat is and what is not productive.

COMPANY NAME NAME OF PRESENTER19






TEAM BUILDING









What is Team Building?

• Supporting Team Members• Sharing Knowledge• Being Courteous• Going Beyond the Norm• Properly Documenting the Product • Properly Following the Methodology• Answering Correspondence Even when it is Inconvenient• Transparency• Truthfulness• Reading about Leadership and Management/

Taking a Leadership Seminar









What is NOT Team Building?

• Blame Finding and Finger Pointing• Defiant Conformance• Rude Behavior• Not Responding to Phone Calls, Emails or Texts• Arguing• Not Showing On Time for Meetings• Email Flooding• Nit Picking Team Members with the intent for them to Quit or Criticizing• Lying• Gossiping and Rumor Starting• Excluding Team Members from Key Activities• Blind Carbon Copying without the knowledge of others• Conference Calling without the Other Party's knowledge• Hoarding Information• Interrupting Others During Meetings, Spotlight Seeking During Meetings & Rambling and not allowing other's to Talk During

Meetings• Conspiring and Backdoor Deals• We Can’t Do that Here, Our atmosphere is different – We want change but we want it the same• The Lead Doesn’t Know the Business• No Proper Management Training (Everyone thinks they can manage)



Efficient and Effective





PRODUCTIVITY







What is Productive?

• Efficiency• Consistency• Organization• Courtesy• Documentation

• Team Contact Lists• Deliverables List or Clear Statement of Work• Context, System, Database & Workflow Diagrams• Coding Standards• Project Management Standards• Abbreviations List• Delivery Timelines• Complete Test Plans

• Test Data (Obfuscated Production Data)• Following Well Developed Industry Standards• A Well Organized Document Repository• Reproducing Success• A Well Devised Workflow for Software and System Development• Low or Non Existent Turn Over• A Healthy Work Environment• Implementing the Methodology Expediently (Band-Aid)• KIS = Less Points of Failure


PRODUCTIVITY



Robert R. Betcher, PMP, CSM





Well-organized Release/ Sprint Meeting Life Cycle

PRODUCTIVITY







What is NOT Productive? (67% of all projects fail)

• Numerous Meetings – the average meeting can cost $1,350 with a chance of a productive outcome of less than 5%. The worst odds in Las Vegas Gaming is 47% (Keno).

• Email Blasting or Flooding (Intentional or Unintentional)• Coming to Meetings Late• Documentation that Offers No or Little Value• Intentionally withholding Information• "We Don't Do That Here." Or "That isn't how we usually do things"• Micro Management• Bickering and Pettiness• Not questioning inefficient processes• Not following proven industry standards• Anyone who hasn’t worked here can’t offer fresh insight• You have to know the business to be effective


PRODUCTIVITY



Well Formed Teams





Team work







Five Characteristics of Well Formed Projects/ Teams(Forming, Storming, Norming and Performing)

1) LEAN Documentation (not too much, not too little)2) Well Formed Teams (little or no turn over, little strife)3) Strong Team Ethics (Work and Moral)4) Clear Vision and Scope5) Strong Servant Leadership

Well Formed Teams

Team work







Five Characteristics of MAL Formed Projects/ Teams

1) Little or No Documentation2) Constant Turmoil and Constant Churning of Staff3) Team Members with Agendas4) Persistent Changing of Direction w/ no clear end in mind (Dis organization)5) No formal or informal training for Managers and

Staff

Well Formed Teams

Team work



Robert R. Betcher, PMP, CSM, ACP





My Career began as a Junior Developer w/ Visual Basic 4.0. After working my way up to Team Lead/ Architect in Java, I switched over to Management, then Project/ Program Management where I have worked on the Following Projects:

1) Java Development2) .Net Development3) Database Migrations4) Document Imaging5) Infrastructure / VOIP6) Data Warehouse7) Identity Management8) Infrastructure Migration

In my spare time, I write articles about Project Management that can be found on Ezines.com and found that I really know only a fraction of what there is to know in technology and Management.

My Experience

About the Author

COMPANY NAME30

Product OwnerRepresents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business. The Product Owner writes (or has the team write) customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog. Scrum teams should have one Product Owner, and while they may also be a member of the development team, it is recommended that this role not be combined with that of the ScrumMaster. (not the PM or the Project Director)

SCRUM MasterScrum is facilitated by a ScrumMaster, who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The ScrumMaster is not the team leader, but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster's role is to protect the Development Team and keep it focused on the tasks at hand. The role has also been referred to as a servant-leader to reinforce these dual perspectives. The ScrumMaster differs from a Project Manager in that the latter may have people management responsibilities unrelated to the role of ScrumMaster. The ScrumMaster role excludes any such additional people responsibilities. (not a project secretary, coordinator or manager)

Glossary of Terms

COMPANY NAME31

Team MemberThe Development Team is responsible for delivering potentially shippable product increments at the end of each Sprint. A Development Team is made up of 3–9 people with cross-functional skills who do the actual work (analyze, design, develop, test, technical communication, document, etc.). The Development Team in Scrum is self-organizing, even though they may interface with project management organizations (PMOs).

Product BacklogA prioritized list of high-level requirements.

Glossary of Terms

Sprint BacklogA prioritized list of tasks to be completed during the sprint.

COMPANY NAME32

SprintA time period (typically 1–4 weeks) in which development occurs on a set of backlog items that the team has committed to. Also commonly referred to as a Time-box or iteration.

User StoryA feature that is added to the backlog is commonly referred to as a story and has a specific suggested structure. The structure of a story is: "As a <user type> I want to <do some action> so that <desired result>" This is done so that the development team can identify the user, action and required result in a request and is a simple way of writing requests that anyone can understand. Example: As a wiki user I want a tools menu on the edit screen so that I can easily apply font formatting. A story is an independent, negotiable, valuable, estimable, small, testable requirement ("INVEST"). Despite being independent, i.e., they have no direct dependencies with other requirements, stories may be clustered into epics when represented on a product roadmap or further down in the backlog.

Glossary of Terms

COMPANY NAME33

ThemeA theme is a top-level objective that may span projects and products. Themes may be broken down into sub-themes, which are more likely to be product-specific. Themes can be used at both program and project level to drive strategic alignment and communicate a clear direction.

EpicAn epic is a group of related stories, mainly used in product roadmaps and the backlog for features that have not yet been analyzed enough to break down into component stories, which should be done before bringing it into a sprint so to reduce uncertainty. Epics can also be used at a both program and project level.

Spike(Technical or Functional) A time boxed period used to research a concept and/or create a simple prototype. Spikes can either be planned to take place in between sprints or, for larger teams, a spike might be accepted as one of many sprint delivery objectives. Spikes are often introduced before the delivery of large epics or user stories in order to secure budget, expand knowledge, and/or produce a proof of concept. The duration and objective(s) of a spike will be agreed between the Product Owner and Delivery Team before the start. Spikes may or may not deliver tangible, shippable, valuable functionality. For example, the objective of a spike might be to successfully reach a decision on a course of action. The spike is over when the time is up, not necessarily when the objective has been delivered.

Glossary of Terms

COMPANY NAME34

Tracer BulletThe tracer bullet is a spike with the current architecture, current technology set, current set of best practices which results in production quality code. It might just be a very narrow implementation of the functionality but is not throw away code. It is of production quality and the rest of the iterations can build on this code. The name has military origins as ammunition that makes the path of the weapon visible, allowing for corrections. Often these implementations are a 'quick shot' through all layers of an application, such as connecting a single form's input field to the back-end, to prove the layers will connect as expected.

Point Scale/Effort/Story pointsRelates to an abstract point system, used to discuss the difficulty of the story, without assigning actual hours. The most common scale used is a rounded Fibonacci sequence (1,2,3,5,8,13,20,40,100), although some teams use linear scale (1,2,3,4...), powers of two (1,2,4,8...), and clothes size (XS, S, M, L, XL).

TasksAdded to the story at the beginning of a sprint and broken down into hours. Each task should not exceed 12 hours, but it's common for teams to insist that a task take no more than a day to finish.

Glossary of Terms

COMPANY NAME35

Definition of Done (DoD)The exit-criteria to determine whether a product backlog item is complete. In many cases the DoD requires that all regression tests should be successful.

SashimiA report that something is "done". The definition of "done" may vary from one Scrum team to another, but must be consistent within one team.

VelocityThe total effort a team is capable of in a sprint. The number is derived by adding all the story points from the last sprint's stories/features. This is a guideline for the team and assists them in understanding how many stories they can do in a sprint.

ImpedimentAnything that prevents a team member from performing work as efficiently as possible.

Glossary of Terms

COMPANY NAME36

Abnormal TerminationThe Product Owner can cancel a Sprint if necessary. The Product Owner may do so with input from the team, ScrumMaster or management. For instance, management may wish to cancel a sprint if external circumstances negate the value of the sprint goal. If a sprint is abnormally terminated, the next step is to conduct a new Sprint planning meeting, where the reason for the termination is reviewed.

Planning PokerIn the Sprint Planning Meeting, the team sits down to estimate its effort for the stories in the backlog. The Product Owner needs these estimates, so that he or she is empowered to effectively prioritize items in the backlog and, as a result, forecast releases based on the team's velocity.

ScrumButA ScrumBut (or Scrum But) is an exception to the "pure" Scrum methodology, where a team has changed the methodology to adapt it to their own needs

Glossary of Terms

COMPANY NAME37

Time BoxA sprint is the basic unit of development in Scrum. The sprint is a "timeboxed" effort, i.e. it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month.

Release Burn Down ChartSprint level progress of completed stories in the Product Backlog.

Sprint Burn Down ChartDaily progress for a Sprint over the sprint's length.

Glossary of Terms

ImpedimentAnything that prevents a team member from performing work as efficiently as possible.

COMPANY NAME38

Daily Scrum (Expanded)A daily scrum meeting in the computing room. This choice of location lets the team start on time each day during the sprint, a project team communication meeting occurs. This is called a daily scrum, or the daily standup. This meeting has specific guidelines:

All members of the development Team come prepared with the updates for the meetingThe meeting starts precisely on time even if some development team members are missingThe meeting should happen at the same location and same time every dayThe meeting length is set (timeboxed) to 15 minutesAll are welcome, but normally only the core roles speak

During the meeting, each team member answers three questions:

What have you done since yesterday?What are you planning to do today?Any impediments/stumbling blocks? Any impediment/stumbling block identified in this meeting is documented by the ScrumMaster and worked towards resolution outside of this meeting. No detailed discussions shall happen in this meeting..

Glossary of Terms

COMPANY NAME39

Backlog GroomingThe team should spend time during a sprint doing product backlog grooming. This is the process of estimating the existing backlog using effort/points, refining the acceptance criteria for individual stories, and breaking larger stories into smaller stories:

Meetings should not be longer than an hourMeeting does not include breaking stories into tasksThe team can decide how many meetings are needed per week.

Scrum of ScrumsThese meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.A designated person from each team attends. The agenda will be the same as the Daily Scrum, plus the following four questions:What has your team done since we last met?What will your team do before we meet again?Is anything slowing your team down or getting in their way?Are you about to put something in another team's way?

Glossary of Terms

COMPANY NAME40

Sprint Planning MeetingAt the beginning of the sprint cycle (every 7–30 days), a "Sprint planning meeting" is held:

Select what work is to be donePrepare the Sprint Backlog that details the time it will take to do that work, with the entire teamIdentify and communicate how much of the work is likely to be done during the current sprintEight-hour time limit (1st four hours) Entire team: dialog for prioritizing the Product Backlog(2nd four hours) Development Team: hashing out a plan for the Sprint, resulting in the Sprint Backlog

Sprint ReviewReview the work that was completed and not completed.Present the completed work to the stakeholders (a.k.a. "the demo")Incomplete work cannot be demonstratedFour-hour time limit

Glossary of Terms

COMPANY NAME41

Sprint RetrospectiveAll team members reflect on the past sprintMake continuous process improvementsTwo main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?Three-hour time limitThis meeting is facilitated by the ScrumMaster

Glossary of Terms

COMPANY NAME42

SCRUM-banis a software production model based on Scrum and Kanban. Scrum-ban is especially suited for maintenance projects or (system) projects with frequent and unexpected user stories or programming errors. In such cases the time-limited sprints of the Scrum model are of no appreciable use, but Scrum's daily meetings and other practices can be applied, depending on the team and the situation at hand. Visualization of the work stages and limitations for simultaneous unfinished user stories and defects are familiar from the Kanban model. Using these methods, the team's workflow is directed in a way that allows for minimum completion time for each user story or programming error, and on the other hand ensures each team member is constantly employed.To illustrate each stage of work, teams working in the same space often use post-it notes or a large whiteboard. In the case of decentralized teams, stage-illustration such as Assembla, ScrumWorks, Rational Team Concert or JIRA in combination with GreenHopper can be used to visualize each team's user stories, defects and tasks divided into separate phases.In their simplest, the tasks or usage stories are categorized into the work stages:UnstartedOngoingCompletedIf desired, though, the teams can add more stages of work (such as "defined", "designed", "tested" or "delivered").

Glossary of Terms

COMPANY NAME43

User Story (Expanded)User Story Example (Anyone should be able to read this and understand it)

user story describes functionality of a system that will be valuable to a NDT stakeholder of a system or software. User stories are composed of three aspects:•a written description of the story used for planning and as a reminder•conversations about the story that serve to flesh out the details of the story•acceptance tests that convey and document details and that can be used to determine when a story is complete

1)A bank customer can change his PIN. 2)As a student, I can find my grades online so that I don’t have to wait until the next day to know whether I passed. 3)One level of undo 4)As a book shopper, I can read reviews of a selected book to help me decide whether to buy it. 5)As an author, I want the spell checker to ignore words with numbers so that only truly misspelled words are indicated

Glossary of Terms

COMPANY NAME44

Conditions of Satisfaction (Expanded)Conditions of Satisfaction ExampleVerify all Data has been exported to X Directory. Completion of User Acceptance Testing.

Glossary of Terms

scrum right - scrum for enterprise environments

Technology

scrum tool

client scrum process

team sprint backlog

nest scrum meeting

hr scrum team backlog

sprint reviews

h sprint backlog features

product roadmaps