Dail Scrum Meeting

4. Daily Scrum Meeting
Our team has already conducted a backlog and Sprint Planning Meeting.  This team meet each morning like most Scrum team in the team room.  If we have

people to serve on a role, obviously they must adjust that. Team Room:

Committed Backlog Items                   Not Started                      In Progress                    Completed

Task board looks messy but it is for their use.

ScrumMaster: Hello, as your ScrumMaster, I'm here to help you with your daily Scrum Meeting. We do this at the same time, same place, each day, standing

up for 15 minutes.

Team Member: so, what is the ajenda. We only have 15 mins.

Scrum Master:  At this meeting, each of you will report to the rest o the team your answers to the three questions.

Quiz1: Scrum Master

Which of the following are explicitly defined questions in the Dail Scrum Meeting?
Yes A. What will I do today ( Or before the next Scrum meeting)?
No B. What are my actuals compared to my estimates ( in hours or days)?
Yes C. What impedes me ( blocks my progress, reduces my effectiveness, etc.)?
No D. What time is the next Daily Scrum Meeting?
Yes E. What did I do yesterday ( or since the last Scrum meeting)?

ScrumMaster: As a self-organizing team you're collectively  responsible for collaborating with each other, and this meeting can help remind you to do that.
To help with that , there are three suggested questions:
Daily Scrum three questions:
A. What will I do today ( Or before the next Scrum meeting)?
B.What impedes me ( blocks my progress, reduces my effectiveness, etc.)?
C.What did I do yesterday ( or since the last Scrum meeting)?
I'll start. Yesterday I went to the facilities Department to get better blinds for the team room windows because you guys said you couldn't see your screens

on sunny days.  Also yesterday I dropped by to visit Sammy Seagull-- that sales manager who keeps asking a couple of you for special fovors-- to show him

where his request are on the product backlog and how to reach the product owner about moving them up.  I think he knew that, but he didn't realize the

effects of distracting the team were so visible to everyone now that we're doing two week iterations.
Today I'll be with you here in the team room because a couple of you said you wanted help learning Test Driven Development.
My impediments today...Sometimes I know what needs to be done, but struggle with the courage to do it. I'm finding it difficult to persuade the other

ScrumMasters to contibute to the organizational impediments list we posted on the wall. (7 obstacles to Enterprise Agility by Michael James)

Team Member 1: Hi team, Yesterday I finished mapping the legacy database schema....at least the parts that we'll need for the View Grades PBI. I'm not a

database expert, but I got a lot of help from Peter, who is.  So, now we both know it. We checked each other's work, so I'm going to move this task to

"completed". 
Today I will start on the code to read the grades from the legacy database, writing tests at the same time, as I've started learning. I've like to pair program

with Andy on this.

Quiz 2: Has the team member finished her report to the team?
Yes A. No. She did not report her impediments yet.
No B. Yes. She said when she did yesterday, and what she will do today. She even showed us how they relate to the Sprint goals on the taskboard.

ScrumMaster: You forgot to answer the third question! Tell us whether you have any impediments.

Team Member 1: I was just getting to that. I'm uncertain whether the automated tests should go all the way to the database tables written by the legacy

system, or if I should just use mock objects.

Team Member 2: I've got some ideas about that. I'll work with you on it.

Quiz 3: Team member
Test Driven Development (TDD) involves creating tests and code nearly simultaneously, while constantly improving the design.  Many Agile

developersdevelopers believe TDD helps ensure correct implementation while reducing the cost of change. Id TDD part of Scrum.
No A. Yes. Scrum is a complete methodology containing everything you need to succeed.
Yes B. No Scrum is only a management framework. It does not specify particular technical practices.

Team Member 2: Wait a minute. our Product Owner isn't here.

ScrumMaster:  Yes, today the product Owner is out sharing our product vision with the CEO.

TeamMember2: I thought the product Owner was supposed to be at every Daily Scrum.  Even though we've got other business expertise on the team, the

product Owner is the final arbiter of requirements questions.

Team Member 3: I thought the product owner was not allowed at the daily Scrum.  We'll never know our true potential for self organization if someone who

outranks us in the company watches our every move.

Team Member 1: Yeah! Plus if we can't function one day without the product Owner, the organization might delegate the role to someone with no real

vision or authority, just because they're less busy. Atleast our product can influence the CEO.  Would you rather have clueless Clyde or Myopic Myron?

ScrumMaster: While the Product owner has an explicit role in the other meetings, Scrum's rules all the Product Owner to either attend, or not attend, the

daily scrum.  as with Many issues, Scrum leaves this for the team to decide.

Team member1: Are we on topic for the daily Scrum

Team Member 2: No. probabily not. This should probably be a sidebar.

ScrumMaster; Let's keep a list of sidebar topics so whoevr's interested can discuss after the meeting.
SIDEBAR:
* Team agreement whether to require Product Owner at Daily Scrum

Quiz 4: ScrumMaster
Which is the timebox for the Daily Scrum Meeting?
No A. As long as necessary
No B. 1 hour
Yes C 15 mins

TeamMember 2:
 Yesterday, I did the page layout for the View Grades PBI, with help from Andy, who checked my work. Today I'd like to write the related HTML and

stylesheet.

Team Member 3: I'll Pai program with you. We're still cleaning up the mess from the last time we wrote code without pair programming.

Team Member 2: My only impediment is that I wanted to show our page layout to the product Owner for feedback, and he's not here.  I'll add a task to

make sure it doesn't get forgotten.

Quiz5: Team member
Many people feel pair programming reduces errors and increases maintainability. What is pair programming?
Yes A. Two people share one workstation, typically taking turns typing while others pay attention and helps.
No B. One person checks in code so another person can review it later, leaving a clear audit trail to the 'single wringable nect' when errors are discovered.
No. C. Code is wtritten two lines at a time to reduce errors.

TeamMember 3:  Ok Team. What I did, What I will do, and what impedes me. I spent yesterday pair programming with Tim on the Update Grades PBI,

using Test Driven Development (TDD). As you all know, that includes writing few lines of failing test code, then writing few lines of the product code, then

refactoring to improve the design without changing behavior and then we did the whole process again.

Failing Tests
Write tests ->Write Product Code -> Refactor code -> Write tests

Team Member 4: Tim and I went through that cycle many times yesterday. Finally getting the normal use case done. Tim helped me find an error condition:

we corrupt the database if the legacy system tries to write the same record at the same time. So I'm adding a new task for us to handle the database

contention. 
Today I 'd like to keep working on this if it's OK with you guys.
I do have one impediment today: I have to leave work early to get my dad from the airport.

Team Member 5:  Hi Team. As Carla Said, I spent most of yesterday pair programming with her on the Update Grade PBI. As a traditional tester, I'm not

very familiar with programming. But since Carla was describing her thoughts as writing the code, I found I could contribute a lot. I was able to point out

edge cases she wouldn't have thought of, write some of the automated tests, and spot messy code so we could refactor it.
Today I want to keep working with Carla on the database contention issue with Update Grades.
As far as impediments: I'm an introvert. I'm still getting accustomed to the amount of interaction expected on the Scrum team.  Sometime I need to retreat

to my old office to take a break.

Team Member 6: Ok team. What I did, What I will do, and what impedes me.  Yesterday I got our new continuous Integration server running.  It reruns all

the tests everytime we make a code change and alert us instantly about regression failures.
Today I plan to plug our old tests into our new continuous Integration process.

Hey, where is Eddie anyway? Eddie's in space-time continuum.

Eddie: Hi guys, sorry I'm late again. Did I miss anything?

Quiz 6:
Other than Eddie, who is responsible for the integeity of Eddie's agreements with his team?
Yes A. The team, and the ScrumMaster must help create the circumstances for the team to take this responsibility. This may include techniques such as

nudging people and modeling behavior.

No B. The ScrumMaster, The ScrumMaster manages the team.

No C. The product Owner. The product owner is in charge.

Team member:  Eddie, I know you were up all night working on the build file by yourself, and you probably thinks this speeds us up. But, we see product

development primarily as knowledge creation, not just construction.When you work in isolations and miss meetings like this one, it actually slows us down

in the long run.
Let's talk about this offline, in another sidebar. I'll try to mediate.

ScrumMaster: We've got some sidebar topics here that some of you want to stay and talk about afterwards.

The daily Scrum is over.

Quiz 7.
The daily Scrum is one technique to encourage team collaboration. Which physical arrangement encourages collaboration the most?

Yes A. Standing in an unobstructed circle, without laptops or phones.

No B. In a typical conference room, with large comfortible chairs encouraging people to stay longer.

No C. In a typical classroom set up, with all chairs facing the front of the room.

Quiz 8.
What is a good size for a Sprint task?
No A. 2-3 people 2-3 days, so that every Product Backlog Item equals one Sprint Task.
Yes B. One person day or less, so other team members can easily defect when a task is stuck.

Quiz 9
During Sprint Execution, a Scrum Team uses 'information radiators' such as  the taskboard or sometimes Sprint Burndown Chart.  Who are these for?

Yes A. The team, so they can take responsibility for their own work habits.
No B. Outside managers, so they can intervene as soon as they don't like how a Sprint is going.

Quiz 10
Martin Fowler's book refactoring: Improving the Design of Existing Code helped popularize  the term "refactoring". The term is often misused. What does

this term mean when applied to source code?
Yes A. Improving internal structure only e.g. removing duplicate code.
No B. Improving functional behavioronly, e.g. fixing bugs
No C. Improving both internal structure and functional behavior.

Quiz 11
Some scrum team fully embrace Agile technical practices. How often do these teams integrate their work and rerun the regression tests?
Yes A. Continuously as things change; potentially many times per day
No B. Once per day ( or night)
No C. Only at the end of each Sprint

Quiz 12
When is Sprint execution completed?
No A. When all tasks are complete.
No. B. It depends
Yes. C. When the timebox expires.
No. When all committed Product backlog Items meet their definition of "done"

Sprint Planning Meeting with sample role play by Collabnet

3. Sprint Planning meeting 
Notes from the video: I have tried to type the contents in this video as part of my reference.  Please check the video link.

Team has already conducted backlog refinement meeting. Now we are ready for Sprint Planning meeting. 
Team Room
Scrum Master: Hello. As your ScrumMaster, I'll be facilitating our sprint planning meeting. During this meeting the product owner and the development

team will agree to sprint goals and will negotiate which items from the product backlog will be committed to the sprint backlog.  We have a 4 hour timebox

to plan  in a 2 weeks sprint. Any questions?
typically on 1st wk Monday 9am to 1pm
--(Two week sprint (wk 1 M-F and wk 2-M-F)
--Wk -1Monday- Sprint planning meeting (4 hours- 9 am to 1 pm), wk 2 Wed Backlog Refinement Meeting ( 2 hours 1-3pm), Sprint review meeting 2nd
--Friday (2 hrs 10-12) noon and again 2nd week Friday (2 hours 1-3pm).)

Quiz 1 (scrum master)
What's the difference between the product backlog and the sprint backlog?
No A. There is no difference
No B. The product backlog contains features, while sprint backlog contains bugs.
Yes C. The product backlog contains everything we might ever work on, while sprint backlog contains just the things we'll work on during one sprint.

Scrum Master: Also during this meeting, the team will come up with an initial list of tasks necessary to complete the committed PBIs.
_________________________________________________________
|Committed backlog items       Not started  In Progress completed           |
|_________________________________________________________|

Quiz 2: Scrum Master
Should the team expect to know all the tasks necessary to complete the committed PBIs during the Sprint Planning Meeting?
Yes A. No. According to Agile Management with Scrum, only 60% of the tasks are likely to be identified during the Sprint Planning Meeting.  Other tasks,

such as unanticipated dependencies, will be discovered during Sprint execution.
No B. Yes. The most important thing is to make sure everyone is busy every hour of the entire Sprint.

Scrum Master: In the original scrum book, this is a 2 part meeting. Sprint Planning Part 1 is for committing the product Backlog Items (PBIs), and Sprint

Planning Part 2 is for coming up with tasks.  This is important for multi-team Scrum. Since we are only one team and the product owner is available the

whole meeting, we can mix up the two parts.  Product Owner, is the product proritized the way you want it?

Product Owner: Well, mostly.  I just realized that GPA is more important than Attendance.

As a student, I see my grades online so that I don't have to wait until  get to school to know whether I'm passing. Acceptance Criteria/Done.
                      View Grades, current semester: As a student, I can see my grades online so that I don't have to wait until I get to school to know whether I'm

passing.
                        As a teacher, I can update grades online so I no longer depend on administrators to do it for me.
                GPA
                Attendance
                Event Calendar
                Alumni Archives
               Scholarship award
               Report Card
               View Grades, previous semester: As a student, I can see my old grades because I lost my report card.

Product Owner continued: That's more like it. Fortunately we got the Product Backlog into good shape during the last Product Backlog Refinement Meeting.

Team Member:  How long is the Sprint that we are planning?

Quiz 3:  Team member
What is the longest allowable iteration, or Sprint, in Scrum?
Yes A. 30. days, or one month calendar month
No  B. Six weeks
No  C. It depends how much work was committed to the Sprint.

Scrum Master: we do two weeks Sprints on this team.

Team Member: two weeks? So we'll do the testing in another sprint?

Quiz4
No A. Yes. We cannot learn how to code and test in one Sprint.
Yes B   No. In

Scrum Master Continued: Scrum teams attempt to build a potentially shippable product incremenat every sprint.  This requires every Sprint to have a mix of

analysis, design, implementation, testing,integration and even deployment.

Team Member: How will we get all that done in two weeks?

Scrum Master: During Backlog Refinement, we divided the original epics into smaller user stories, representing thin vertical slices. We'll still have to work

together during the sprint more than a traditional team. That's why we go to the team room. Also remember it's my job to prevent other people from

interrupting you with unrelated work.

Product Owner: If anyone asks you to do anything unrelated to our Sprint goals, send them to me so we can add it to the Product Backlog. I won't interrupt

your Sprint unless it's an emergency.

Quiz: 5
How can one Scrum team build a potentially shippable product increment within one Sprint?
Yes A. By agreeing to a smaller amount of feature scope at the Sprint Planning Meeting, allowing more time for integration, testing, and fixing during each

Sprint.
Yes B. By using modern software engineering approaches such as test-driven development (TDD), continuous integration, merciless refactoring
Yes C. By improved collaboration techniques: pair programming, working in a team room, and eliminating "over the wall" hand offs.
Yes D. By full-time allocation to one team, focusing on only one set of sprint goals.
Yes E. By checking code in multiple times per day, and by reducing or eliminating branches in the version control system
Yes F. By organizing teams around features rather than architectual components.
No G. They cannot do it. It's too difficult to code and test in one sprint.

Quiz 6
A 30-day Sprint uses a 1-day timebox for the Sprint Planning Meeting. How long should the Sprint should the Sprint Planning Meeting be for two weeks

Sprint?
No A. 1 day
No B. 15 minutes
Yes C. 4 hours
No D. 1 hour

ScrumMaster: Don't forget the timebox, guys.  You have 4 hours to plan a two week Sprint.

Team Member: What are our goals for this Sprint.

Product owner: This Sprint I'd be happy to see some rudimentary capabilities with grading.

Team Member: This is the product Owner's top prority item. Do the rest of you think we could do this in our two-week Sprint?

Product Owner:View Grades, Current Semester:
                           As a student, I can see my grades online so that I don't have to wait until I get to school to know whether I'm passing.
                          Acceptance criteria: Columns align neatly on Fingerfly 4.1 and IPhone
                          Effort: SMALL

Team member: What's our definition of done?

Quiz7: ScrumMaster
To avoid technical debt, what should the team write down in their definition of done?
Yes A. All previous regression tests pass.
Yes B. Regression tests for new functionality run automatically with every build.
Yes C. Code has been written by pairs, or at least reviewed by other team members.
No D. Nothing.  It is not helpful to write down important agreements
Yes E. Duplicate code has been removed through refactoring
Yes F Messy and poorly designed code has been cleaned up through refactoring.
Yes G. Manual, exploratory testing has been conducted.
Yes H. Checkout and build are fully reproducible, typically with one or two commands.

ScrumMaster: Done is properly tested, refactored, potentially shippable

Team Member: I think I get it. We're building a product increment which could be shipped if the product Owner decided it has enough features.

Product Owner: I can live with something that works properly. The complexity can be folded in later.

Team Member: Does everyone agree the View Grades, current semester PBI will require some testing tasks?

Committed Backlog Items                                                                       Not Started
View Grades, Current Semester:
 As a student, I can see my grades online so that I don't have
to wait until I get to school to know whether I'm passing.
Acceptance criteria: Columns align neatly on Fingerfly 4.1 and IPhone
Effort: SMALL

Quiz 8: Team Member
Do you agree the PBI will need some testing tasks?
Yes A. Yes. If the team learns to use Test Driven Development (TDD), some of this will be handled implicitly and repeatably. Manual exploratory testing is

also important.

No B. No. Testing should be done at the end of the project.  There's always enough time at the end of the project.

Scrum Master: ( adds Test to not Started)
Committed Backlog Items                                                                       Not Started
View Grades, Current Semester:                                                                   Test
 As a student, I can see my grades online so that I don't have
to wait until I get to school to know whether I'm passing.
Acceptance criteria: Columns align neatly on Fingerfly 4.1 and IPhone
Effort: SMALL

Team Member: Also, we have to decide how to access the grades database,
Committed Backlog Items                                                                       Not Started
View Grades, Current Semester:                                                                   Test, grades database
 As a student, I can see my grades online so that I don't have
to wait until I get to school to know whether I'm passing.
Acceptance criteria: Columns align neatly on Fingerfly 4.1 and IPhone
Effort: SMALL

Team Member: It will take a little design  work to lay out the page.

ScrumMaster: ( adds Page layout)
Committed Backlog Items                                                                              Not Started
View Grades, Current Semester:                                                                   Test, grades database,
 As a student, I can see my grades online so that I don't have                        Page Layout
to wait until I get to school to know whether I'm passing.
Acceptance criteria: Columns align neatly on Fingerfly 4.1 and IPhone
Effort: SMALL

Team Member -1: What about the code?

Team Member -2: Write code using test driven development (TDD) and pair programming

Team Member -1: Our Test driven Development (TDD) skills aren't that good yet.  This will take a bit longer than our old way of working.

ScrumMaster:  Yes, initially it will feel like going slower. If you commit as a team to use Agile engineering practices consistently, you'll eventually be faster

from a business perspective.  Using craftmanship to build innovative products is not about how fast you type code. What other tasks are missing to het this

into a potentially shippable state?

Team Member: Integrate with authentication system, Get feedback from Product owner on page design, update app server to latest version, borrow jphone

from the lab, continuous integration server

Committed Backlog Items                                                                       Not Started
View Grades, Current Semester:                                                                   Test, grades database, Integrate, Page layout, code, feedback, documentation,
 As a student, I can see my grades online so that I don't have                       App server, jphone, Ci server
to wait until I get to school to know whether I'm passing.
Acceptance criteria: Columns align neatly on Fingerfly 4.1 and IPhone
Effort: SMALL

Team Member: Still think we can do this in two weeks, without compromising our definition of done and without working overtime?
 Team: Yes
Team Member: Anyone think we can't do it?

Quiz 9: Team
Who is responsible for committing to work in the Sprint Planning Meeting?
No A. The Project Manager
No B. The ScrumMaster
Yes C. Team

Team: Cool! what about the next one?

Product Manager: Update Grade, current semester
                             As a teacher, I can update grades online so I no longer depend on administrators to do it for me.
                             Effort: medium

ScrumMaster: As we discussed during the Backlog Refinement Meeting, this one's tougher.  Now our product must write our records to the database

without breaking the legacy system.

Team: Write tests proving we don't break the legacy system, Write tests proving the legacy system doesn't break us. analyze the legacy database schema.

Write code using Test driven Development (TDD) and pair programming, write HTML/CSS for update form, get feedback from real teacher, Add link from

the display list to the update form

Committed Backlog Items                                                                       Not Started
View Grades, Current Semester:                                                                   Test, grades database, Integrate, Page layout, code, feedback, documentation,
 As a student, I can see my grades online so that I don't have                       App server, jphone, Ci server
to wait until I get to school to know whether I'm passing.
Acceptance criteria: Columns align neatly on Fingerfly 4.1 and IPhone
Effort: SMALL
Update Grade, current semester                                                                       Write tests proving we don't break the legacy system                                         
As a teacher, I can update grades online so I no longer depend on                    Write tests proving the legacy system doesn't break us   
administrators to do it for me.                                                                           analyze the legacy database schema, Write code usingTDD
Effort: medium                                                                                                   and Pair programming, Write HTML/CSS for Update form
                                                                                                                           Get feedback from teacher, Add link to update form


Team Member: Can we do both of the PBIs in 2 week without compromising definition of done and without working overtime?

Team: Yes

Team Member: Anyone think we can't do it?

Product Owner: What about attendance? I would love to see that working.

Team: No

Team Member: We think this is enough work for one sprint.  Anyway, Attendance isn't related to Sprint goal you declared.

Scrum Master: A Lean principle behind Scrum is to limit Work in progress (WIP).  Humans don't multitask efficiently.  Too much Work in progress (WIP)

actually slows things down.

Quiz10: Scrum Master
Which is a better measure of progress?
No A. How much work has been started.
Yes B. How much work has been finished.

Team Member: That's a lot of tasks. Should we decide which individuals are doing which tasks now?

Scrum Master: We tried that before, and discovered it led to less fluid collaboration than deciding during Sprint execution.

Team Member: Yeah, I signed up for too much in the beginning, and I was embarrased to ask the rest of you for help.

Product Owner: After that, in our Sprint Retrospective Meeting. we decided team members should wait until the last responsible moment to volunteer for

tasks.

ScrumMaster: One last check. Are you committed to these four PBIs as a team, even if it turns out to require different tasks?

Team Member: Yes, if you'll protect us from people asking us to do other things.

ScrumMaster: I'll protect you from people asking you to do other things.

Team Member: Then we'll commit.

Team: Yes!

Product Owner: I'll be available during the Sprint to make the final call about requirements questions. If you like, I can also attend your Daily Scrum

Meetings.

ScrumMaster: I declare the Sprint Planning Meeting over!

Quiz11: Sprint Master
How Many Sprints are planned during a Sprint Planning Meeting?
No A. All the Sprints left in the project. We know more on the first day of a project then we will know in the future.
Yes B. One Sprint only. Once the team has established a consistent velocity, the Product Owner can use this velocity to make longer range forcasts and

release plans.
No C. Four Sprints.

Quiz 12: Sprint Master
Who must attend the Sprint Planning Meeting?
Yes A. product Owner
Yes B. Scrum development Team
Yes C. Scrum Master
No D. Outside Stakeholders
No. E The manager of the team members.

Quiz13: Scrum Master
What does the team attempt to do during its very first Sprint?
Yes A. Analyze, design, build, integrate, and test a potentially shippable product increment, even if its features are initially simple and small.
No  B. Analyze requirements only
No    C. Analyze requirements, and put together infrastucture only.

Quiz 14: Scrum Master
Which of the following are true regarding Product Backlog Items (PBIs) and tasks?
Yes A. A PBI is more about what than the how. A task is more about the how.
Yes B. A well-formed PBI represents distinct business value, ideally from the customer's perspective. A task is just a step by the team to create that value.
Yes C. A task should be no bigger than one day of work.
Yes D. Some Scrum Teams who have learnt how to define small enough pBIs no longer finds tasks necessary
Yes E. A product backlog should contain well forms PBIs and not tasks.

https://www.youtube.com/watch?v=wPvG9NZNUa4

Backlog Refinement Meeting with sample role play by Collabnet

2. Backlog Refinement Meeting .
Notes from the video: I have tried to type the contents in this video as part of my reference.  Please check the video link.

II. Backlog refinement Meeting
Backlog refinement falls outside the scrum, however everyone feels the need to do it. In a two week sprint, typically wk 2 Wed Backlog Refinement Meeting

( 2 hours 1-3pm), typically 2 days before the next sprint.
--(Two week sprint (wk 1 M-F and wk 2-M-F)
--Wk -1Monday- Sprint planning meeting (4 hours- 9 am to 1 pm), wk 2 Wed Backlog Refinement Meeting ( 2 hours 1-3pm), Sprint review meeting 2nd --

Friday (2 hrs 10-12) noon and again 2nd week Friday (2 hours 1-3pm).)
Skit
Team Room: At the backlog refinement meeting, a.k.a backlog grooming, we have a product owner, a cross functional self organizing scrum development

team, scrum master. This team has just started developing a student information system and it helps school track student progress.

Scrum Master: Hello, I'll be facilitating our backlog refinement meeting.  Within 2 hours timebox. WE will attempt to clarify and decompose the higher

priority Product Backlog Items. As you'll recall from our training, any work that represents business value or consumes time and attention from the team

may be worth listing in the product backlog. One objective of this backlog refinement meeting is to create PBIs that are INVEST (Bill Wake)
(INDEPENDENT, NEGOTIABLE, VALUABLE,ESTIMATABLE, SMALL, TESTABLE).  Mr Product owner since you are responsible for the product vision,

and return on investment, why don't you start by telling us your current priorities?

Product Owner: Based on my vision for this product, here are my top priority items:
Grades
Attendance
Even calendar
Alumni Archives
Scholarship award
Product backlog
Product backlog
.....
Oh, I want the pages to look really good. When can you have that done?

Team:  We have no idea! It will be done when it is done! Call us when you've finished writing the requirements.

Quiz 1:
What should the scrum master say next?
No-A. Yes, the development team should wait until marketing department has properly documented all the requirements.
No-B. We're here to refine the requirements together. No one leaves the room until we've refined the entire Product  backlog.
Yes-C. We're here to refine the requirements together. Success at Agile requires business people and the developers to work together daily throughout the

project.


Scrum Master: We're here to refine the requirements together. Success at Agile requires business people and the developers to work together daily

throughout the project. In this meeting let's focus on the top few items only.

Team- tester: I'm just a tester.  I don't know anything about development.  Do you mind if I play with my phone until you start talking about testing?

Quiz 2:
What should the scrum master say next?
No A. I am the scrummaster. That makes you the scrumslave.  I order you to participate.
No B. Since you're only a tester, we don't need you until later.  Give me  your testing estimates offline and I'll add them to the last phase of the project plan.

It's important to maximize resource utilization.
Yes C. Maybe your background and skills were mostly in testing, but now you are a scrum team member. A Scrum development team is collectively

responsible for thin slices of properly tested product every sprint.  Let's ask the team what they think of your involvement.

Scrum Master: Maybe your background and skills were mostly in testing, but now you are a scrum team member. A Scrum development team is collectively

responsible for thin slices of properly tested product every sprint.  Let's ask the team what they think of your involvement.

Team Member-coder: In the past I've just written code and handed it off to another department for testing. You have years of experience with testing. And

now we're in this together.  I'd appreciate your expertise in this meeting.

Team Member- tester: Dude, I do not work for you.

Team Member- coder: Yes you do, just as we work for you. On a self organizing team we all work for each other.

Team Member- tester: oh. okay!

Scrum Master: Since this meeting is timeboxed, I suggest focusing on the top item for now: Grades.  I propose using estimation cards to get a better cross

section of opinions about the effort to get that PBI into potentially shippable form.

(This team like to make an estimation using a game 4 cards per person. ( S, M, L and XL).  We are estimating the effort to complete the grades PBI. Choose

a card, then reveal it at the same time as everyone else.
L, M, S, XL)

Scrum Master: Let's hear the reasoning behind these guesses.

Team Member- coder: S-I picked small because displaying the grades to students is just a few lines of code.
Team Member- tester: XL-I picked Extra large because I can't imagine how we'd start testing such a vague requirements.
Team Member-: L- I picked large because I thought the requirement was to allow teachers to update grades, not just display them.
Product Owner- Actually, what I really want is teachers to be able to update grades, students to be able to view them online, and report cards sent to

parents each semester.
Now I realize I'll need your help refining the grades product backlog Item.

Quiz 3:
Why does grade require additional refinement?
No A. It's not Independant, Negotiable, or Valuable
Yes B. It's not estimateable, small or testable.

Scrum Master: The team seems to feel the grade PBI is actually an epic which can be split into several distinct user stories.  This is one of the purposes of

this Backlog Refinement Meeting.

Grades = Epic ( split to several user stories)
User Story
User Story
User Story
.......

Quiz 4
Do most people use most features of most software products?
No A. Yes. Success depends on pushing hard to get everything done.
Yes B. No. many people wish the 20% of features they actually use the most had been properly tested.

Scrum Master: It turns out most people don't use most features of most products. Even the features they do use can be split into more valuable and less

valuable parts. A well-formed PBI toward the top of the backlog is no bigger than a quarter of a sprint and ideally smaller than that. Maybe we can split the

Grades epic into more valuable parts to get smaller user stories.

Team Member: Generating the report cards will be really hard because it depends onm the reliable third- party PDF libraries.

Product owner: I am willing to put the report cards on the bottom of the backlog, for now, if we can at least allow teachers to update grades online. They

tend to lose their paper records before it's time to turn them in.

Product Owner: Based on my vision for this product, here are my top priority items:
Grades ( without report card)
Attendance
Even calendar
Alumni Archives
Scholarship award
Report cards
Product backlog
Product backlog


Scrum Master: It is often useful to identify who, what and why in a Product Backlog Item.  For Example:

Grades-view grades
Attendance
Even calendar
Alumni Archives
Scholarship award
Report card
Product backlog
Product backlog
.....
View grades: As a student I see my grades online so that .....

Team Member: I don't have to wait until  get to school to know whether I'm passing.

Product owner: Okay, I understand that one now. (As a student, I see my grades online so that I don't have to wait until  get to school to know whether I'm

passing.) It has the who, the what and why.  It's somewhat independent and it represents distinct business value.

(As a student, I see my grades online so that I don't have to wait until  get to school to know whether I'm passing.)- INVEST-(INDEPENDENT,

NEGOTIABLE, VALUABLE,ESTIMATABLE, SMALL, TESTABLE).

Scrum Master: If we work together it may be Small enough to get into potrentially shippable form in a couple of days.

Team Member- Tester: At first glance it seems Testable.

Scrum Master: We'll leave room to add some acceptance criteria.

Product Owner: What about Update Grades? As a teacher, I can update grades online so I no longer depend on administrators to do it for me.

Scrum Master:
                Grades
                         As a student, I see my grades online so that I don't have to wait until  get to school to know whether I'm passing. Acceptance Criteria/Done.
                        As a teacher, I can update grades online so I no longer depend on administrators to do it for me.
                Attendance
                Event Calendar
                Alumni Archives
               Scholarship award
               Report Card

Scrum Master again:  As a teacher, I can update grades online so I no longer depend on administrators to do it for me.  Is this more or less important than

view grades?

Product Owner: Prioritize? I want all these features at once!

Quiz 5:
In effective Scrum, how are priorities represented in the product Backlog?
No A. PBIs are grouped into bucket P1,P2,P3 etc.
Yes B. Items on top are most important than items on the bottom. No two items can be exactly the same priority, especially at the top.

Product Owner: I suppose View grades has the most business value. If we didn't finish Upgrade grades, school administrators could still use the legacy

system to upgrade the grades. I wouldn't be very happy about that though.

Scrum Master: Feel free to re-prioritize the product backlog at any time.

Team Member: We're not committing to do the work in this sequence?

Scrum Master: No commitments are made in the Backlog refinement meetings. Later when we get to the Sprint Planning meeting, you'll decide how much

work to take on within one sprint.

Quiz 6:
Who is ultimately responsible for prioritizing the Product Backlog Items?
No A. The ScrumMaster
Yes B. The Product Owner
No C. The development Team
No D. External Stakeholders
No E. No one. It is done by majority vote.

Team Member: Let's try estimating the view grades PBI.
Product owner: As a student, I see my grades online so that I don't have to wait until  get to school to know whether I'm passing. Acceptance Criteria/Done.

(This team like to make an estimation using a game 4 cards per person. ( S, M, L and XL).  We are estimating the effort to complete the grades PBI. Choose

a card, then reveal it at the same time as everyone else.
L, M, S, XL)

Team Member Coder-S: It is just a few lines of code
Team Member 2-S: I agree it is small. The UI design is simple
Team member 3-S: Since this item doesn't alter the database, both the technical risk and testing effort are low.
Team Member 4-M: I disagree. I picked medium because the previous semesters' grades are kept on a different legacy system.
Team Member coder: Oh Yeah, I forgot. Does this have to work with previous semesters, or just this semester?

Product Owner: I hadn't thought about it until you asked. I'm really interested in the current semester. We won't need the previous semesters until later on.
    As a student, I see my grades online so that I don't have to wait until  get to school to know whether I'm passing. Acceptance Criteria/Done.
        View Grades, current semester: As a student, I can see my grades online so that I don't have to wait until I get to school to know whether I'm passing.
        View Grades, previous semester: As a student, I can see my old grades because I lost my report card.

Grades
                         As a student, I see my grades online so that I don't have to wait until  get to school to know whether I'm passing. Acceptance Criteria/Done.
                                  View Grades, current semester: As a student, I can see my grades online so that I don't have to wait until I get to school to know

whether I'm passing.
                        As a teacher, I can update grades online so I no longer depend on administrators to do it for me.
                Attendance
                Event Calendar
                Alumni Archives
               Scholarship award
               Report Card
               View Grades, previous semester: As a student, I can see my old grades because I lost my report card.

Quiz 7: Scrum master
 What is more important objective of the Backlog Refinement Meeting?
No A. To get precise estimate
No B. To get a better understanding of upcoming work and combine it to form larger PBIs
Yes C. To get a better understanding of upcoming work and combine it to form smaller PBIs
No D. To get a better understanding of upcoming work and create monolithic, detailed design decument.

Scrum Master: As a student, I see my grades online so that I don't have to wait until  get to school to know whether I'm passing. Acceptance Criteria/Done.
Revote? L-S-S-S
Team Member 1-L: Looks like I'm the outlier this time. I just realized what a pain it will be to get the table display working on Ethernet Exploiter 6.
Team Member 2- EE6?? I thought we only had to support FingerFly now!

Product Owner: That's correct. The district has banned the use of Ethernet Exploiter, especially EE6.

Scrum Master: Let's make that explicit in the acceptance criteria.
                     View Grades, current semester: As a student, I can see my grades online so that I don't have to wait until I get to school to know
                 
                     Acceptance criteria/Done:
                     Works on FingerFly

Team Member 1-S: In that case I am good with small.

Scrum Master:
                     View Grades, current semester: As a student, I can see my grades online so that I don't have to wait until I get to school to know
                 
                     Acceptance criteria/Done:
                     Works on FingerFly
                      Effort: Small
Quiz 8: Scrum Master

What's the difference between acceptance criteria and definition of done?
No A. There is no difference
Yes B. Definition of done applies globally to all PBIs for a product, while acceptance criteria pertain to specific items.  Acceptance criteria could also form

the basis of new stories.

Scrum Master: Ok, I think that's enough. We've used up our two-hour timebox and I can tell from everyone's body language we're done with this meeting.

Team Member: But we didn't refine the entire Product Backlog!
Team Member: And we never will.

Product Owner: True. But now we have a much better picture than before of what we might do the next couple Sprints.

Scrum Master: Don't forget Agile approaches involve some planning.  We just value responding to change more.  I declare the Backlog Refinement Meeting

over!

Product owner: Backlog refinement meeting is also called
                          a.k.a  Product Backlog Grooming
                          a.k.a  Backlog estimation
                          a.k.a  Story time
The team should set aside for this every single sprint.
For example for a two weeks sprint, the team should take 2 hours break for product backlog refinement meeting

The purpose of the backlog  refinement meeting is to help the product owner to keep the top of the product backlog ready for the next sprint planing

meeting. if there was no product backlog meeting  during sprint execution, in the very first sprint, you will need more time in the very first sprint planning

meeting. Product owner cannot do this alone. The whole team has to help. Agile is business people and technical people working together constantly.

Product owner must make the final call about the requirements, especially the prioritization.  Backlog refinement includes estimation of effort, clarification of

requirements and decomposition of large PBIs into smaller ones (e.g. epics to user stories)

To learn more about Scrum:
refer Scrum Reference card, Example ScrumMaster's checklist.
Tools ScrumWorks Pro, TeamForge, Subversion

https://www.youtube.com/watch?v=b_WeHcZcx1w

Collabnet resource link

Published on Apr 27, 2012

This module covers the hidden fifth meeting that's essential to success at Scrum and other Agile approaches. Subtopics include how to recognize well-formed Product Backlog Items (PBIs), a team effort estimation game, decomposition of large PBIs (e.g. "epics") into smaller ones (e.g. "user stories"), acceptance criteria, definition of done, Product Backlog prioritization, and team self organization. This is an interactive, scenario based module. The learner observes a simulated team and is prompted to help them as they face various challenges. See the entire series!
http://www.collab.net/services/training/agile_e-learning

INVEST by Bill Wake 
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

Definition of Done 
http://blogs.collab.net/agile/suggested-topics-for-definition-of-done-discussion#.U9f_aPldX1Y

Agile Manifesto 
http://AgileManifesto.org 

For the full quality, interactive version of this video, see:http://www.collab.net/services/training/agile_e-learning

Find a Scrum class in your city:http://www.collab.net/services/traini... 

Scrum Reference Card: http://www.collab.net/sites/default/files/uploads/CollabNet_scrumreferencecard.pdf

Example ScrumMaster's Checklist:http://www.collab.net/sites/default/files/uploads/ScrumMaster_Checklist.pdf

ScrumMaster_Checklist

http://www.collab.net/sites/default/files/uploads/ScrumMaster_Checklist.pdf
(please check the pdf).  Still working on fixing the text formatting

An Example Checklist for ScrumMasters
Michael James
 (MJ@collab.net)
CollabNet, Inc.
14 September 2007
(Revised 24 July 2012)
A Full Time Facilitator?
An adequate ScrumMaster can handle two or three teams at a time. If you're content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation at your organization, and probably nothing catastrophic will happen.
But if you can envision a team that has a great time accomplishing things no one previously thought possible, within a transformed organization, consider being a great ScrumMaster.
A great ScrumMaster can handle one team at a time.
We recommend one dedicated ScrumMaster per team of about seven, especially when starting out.
If you haven't discovered all the work there is to do, tune in to your Product Owner, your team, your team's engineering practices, and the organization outside your team. While there's no single prescription for everyone,
I've outlined typical things I've seen ScrumMasters overlook. Please mark each box with √, ∆, ?, or N/A, as described on the last page.

Part I -- How Is My Product Owner Doing?
ScrumMasters improve Product Owner effectiveness by helping them find ways to maintain the Product Backlog and release plan. (Note that only the Product Owner may prioritize the backlog.)
☐ Is the Product Backlog prioritized according to his/her latest thinking?
☐ Are requirements and desirements from all stakeholders captured in the Product Backlog? Remember: the backlog is emergent.
☐ Is the Product Backlog a manageable size? To maintain a manageable number of items, keep things more granular towards the top, with general epics at the bottom. It's counterproductive to overanalyze too far past the top of the Product Backlog. Your requirements will change in an ongoing conversation between the developing product and the stakeholders/customers.
☐ Could any requirements (especially those near the top of the Product Backlog) be better expressed as independent, negotiable, valuable, estimable, small, and testable user stories1?
☐ Have you educated your Product Owner about technical debt and how to avoid it? One piece of the puzzle may be to write automated test and refactoring into the definition of "done" for each backlog item.
☐ Is the backlog an information radiator, immediately visible to all stakeholders?
☐ If you're using an automated tool for backlog management, does everyone know how to use it easily?
Automated management tools introduce the danger of becoming information refrigerators without active radiation from the ScrumMaster.
 Copyright © 2007-2012 Michael James. All Rights Reserved.
1 http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
☐ Can you help radiate information by showing everyone printouts?
☐ Can you help radiate information by creating big visible charts?
☐ Have you helped your Product Owner organize backlog items into appropriate releases or priority groups?
☐ Does everyone know whether the release plan still matches reality?
You might try showing everyone Product/Release Burndown Charts

2 after the items have been acknowledged as “done” during every Sprint Review
Meeting. Charts showing both the rate of PBIs actually completed and new ones added allow early discovery of scope/schedule drift.
☐ Did your Product Owner adjust the release plan after the last Sprint Review Meeting? The minority of Product
Owners who ship adequately tested products on time re-plan the release every Sprint. This probably requires
deferring some work for future releases as more important work is discovered.
Part II -- How Is My Team Doing?
While you are encouraged to lead by the example of collaborating with team members on their work, there is a risk you will get lost in technical tasks.
Consider your primary responsibilities to the team:
☐ Is your team in the state of flow? Some characteristics of this state

3:
• Clear goals (expectations and rules are discernible and goals are attainable, aligning appropriately with
one's skill set and abilities).
• Concentration and focus, a high degree of concentration on a limited field of attention.
• A loss of the feeling of self-consciousness, the merging of action and awareness.
• Direct and immediate feedback (successes and failures in the course of the activity are apparent, so that behavior can be adjusted as needed).
• Balance between ability level and challenge (the activity is neither too easy nor too difficult).
• A sense of personal control over the situation or activity.
• The activity is intrinsically rewarding, so there is an effortlessness of action.
☐ Do team members seem to like each other, goof off together, and celebrate each other's success?
☐ Do team members hold each other accountable to high standards, and challenge each other to grow?
☐ Are there issues/opportunities the team isn't discussing because they're too uncomfortable?4
☐ Have you tried a variety of formats and locations for Sprint Retrospective Meetings?5
☐ Has the team kept focus on Sprint goals? Perhaps you should conduct a mid-Sprint checkup to re-review the acceptance criteria of the Product Backlog Items committed for this Sprint.
 Copyright © 2007-2012 Michael James. All Rights Reserved.

2 Mike Cohn, Agile Estimation and Planning. (2005).
3 Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (1990).
4 Kerry Patterson, Crucial Conversations: Tools for Talking When Stakes are High (2002). Also consider enlisting a professional facilitator who can make uncomfortable conversations more comfortable.
5 Derby/Larson Agile Retrospectives: Making Good Teams Great (2006). ☐ Does the Sprint taskboard reflect what the team is actually doing? Beware the “dark matter” of undisclosed tasks and tasks bigger than one day’s work. Tasks not related to Sprint commitments are impediments to
those commitments.
☐ Does your team have 3-9 people with a sufficient mix of skills to build a potentially shippable product increment?
☐ Is your team's taskboard up to date?
☐ Are the team self-management artifacts (taskboard, Sprint Burndown Chart, impediments list, etc.) visible to the team, convenient for the team to use?
☐ Are these artifacts adequately protected from meddlers? Excess scrutiny of daily activity by people outside the team may impede team internal transparency and self management.
☐ Do team members volunteer for tasks?
☐ Has the need for technical debt repayment been made explicit in the backlog items, gradually making the code a more pleasant place to work?
☐ Are team members leaving their job titles at the door of the team room, collectively responsible for all aspects of agreed work (testing, user documentation, etc.)?
Part III -- How Are Our Engineering Practices Doing?
☐ Does your system in development have a "push to test" button allowing anyone (same team or different team) to conveniently detect when they've caused a regression failure (broken previously-working functionality)?
Typically this is achieved through the xUnit framework (JUnit, NUnit, etc.).
☐ Do you have an appropriate balance of automated end-to-end system tests (a.k.a. "functional tests") and automated unit tests?
☐ Is the team writing both system tests and unit tests in the same language as the system they're developing?
Collaboration is not enhanced by proprietary scripting languages or capture playback tools that only a subset of the team knows how to maintain.
☐ Has your team discovered the useful gray area between system tests and unit tests6?
☐ Does a continuous integration7 server automatically sound an alarm when someone causes a regression failure? Can this feedback loop be reduced to hours or minutes? ("Daily builds are for wimps." -- Kent Beck)
☐ Do all tests roll up into the continuous integration server result?
☐ Have team members discovered the joy of continuous design and constant refactoring8, as an alternative to Big Up Front Design? Refactoring has a strict definition: changing internal structure without changing external behavior. Refactoring should occur several times per hour, whenever there is duplicate code, complex conditional logic (visible by excess indenting or long methods), poorly named identifiers, excessive coupling between objects, etc. Refactoring with confidence is only possible with automated test coverage. Neglecting  Copyright © 2007-2012 Michael James. All Rights Reserved.

6 http://blogs.collab.net/agile/2007/03/07/junit-is-not-just-for-unit-testing-anymore/

7 http://www.martinfowler.com/articles/continuousIntegration.html

8 Martin Fowler, Refactoring: Improving the Design of Existing Code (1999).refactoring makes it hard to change the product in the future, especially since it’s hard to find good developers
willing to work on bad code.
☐ Does your definition of "done" for each Product Backlog Item include full automated test coverage and refactoring? Learning Test Driven Development (TDD) increases the probability of achieving this.
☐ Are team members pair programming most of the time? Pair programming may dramatically increase code maintainability and reduce bug rates. It challenges people's boundaries and sometimes seems to take longer (if we measure by lines of code rather than shippable functionality). Lead by example by initiating paired workdays with team members. Some of them will start to prefer working this way.

Part IV -- How Is The Organization Doing?
☐ Is the appropriate amount of inter-team communication happening? “Scrum of Scrums” is only one way to achieve this, and not necessarily the best.
☐ Are teams independently able to produce working features, even spanning architectural boundaries?9
☐ Are your ScrumMasters meeting with each other, working the organizational impediments list?
☐ When appropriate, are the organizational impediments pasted to the wall of the development director's office?
Can the cost be quantified in dollars, lost time to market, lost quality, or lost customer opportunities? (But learn from Ken Schwaber's mistakes: "A dead ScrumMaster is a useless ScrumMaster."
10)
☐ Is your organization one of the few with career paths compatible with the collective goals of your teams?
Answer "no" if there's a career incentive11 to do programming or architecture work at the expense of testing, test automation, or user documentation.
☐ Has your organization been recognized by the trade press or other independent sources as one of the best places to work, or a leader in your industry?
☐ Are you creating a learning organization?
Conclusion
If you can check off most of these items and still have time left during the day, I’d like to hear from you.There’s no canned formula for creating human ingenuity. This paper lists points which may, or may not, help in your situation.
Once you start to realize what you could do to make a difference, you may find yourself afraid to do it. This is a sign you're on the right track.
 Copyright © 2007-2012 Michael James. All Rights Reserved.

9 http://FeatureTeamPrimer.org/

10 Ken Schwaber, Agile Project Management with Scrum (2004)

11 Alfie Kohn, Punished By Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise, and Other Bribes (1999)Organizational Impediment Form
Surface issue:
Root cause (Use five times “Why?”):
Business Impact:
Emotional Impact:
Clear, actionable request:
Organizational Impediment Form
Surface issue:
Root cause (Use five times “Why?”):
Business Impact:
Emotional Impact:
Clear, actionable request:
 Copyright © 2007-2012 Michael James. All Rights Reserved.Organizational Impediment Form
Surface issue:
Root cause (Use five times “Why?”):
Business Impact:
Emotional Impact:
Clear, actionable request:
Organizational Impediment Form
Surface issue:
Root cause (Use five times “Why?”):
Business Impact:
Emotional Impact:
Clear, actionable request:
 Copyright © 2007-2012 Michael James. All Rights Reserved.Organizational Impediment Form
Surface issue:
Root cause (Use five times “Why?”):
Business Impact:
Emotional Impact:
Clear, actionable request:
Organizational Impediment Form
Surface issue:
Root cause (Use five times “Why?”):
Business Impact:
Emotional Impact:
Clear, actionable request:
 Copyright © 2007-2012 Michael James. All Rights Reserved.INSTRUCTIONS
If you have received this checklist as a training assignment and your current
(or most recent) employer has been attempting anything like Scrum, please
apply this to what you’ve seen there. Mark each item with one of the
following:
√ (for “doing well”)
∆ (for “could be improved and I know how to start”)
? (for “could be improved, but how?”)
N/A (for “not applicable” or “would provide no benefit”)
Or, if your current (or most recent) employer has not been attempting
anything like Scrum, mark each item with one of the following:
√ (for “doing well” or “would be easy to do well”)
∆ (for “would be a challenge and I know how to start”)
? (for “would be a challenge and I don’t know how to start”)
N/A (for “not applicable” or “would provide no benefit”)
When all items are marked, declare 2-6 organizational impediments on the
attached Organizational Impediment Forms, whether or not they’re derived
from this checklist. Choose impediments you have at least 1% hope of
changing.
 Copyright © 2007-2012 Michael James. All Rights Reserved.

Introduction to Scrum by Collabnet

1. Introduction to Scrum
Notes from Video: I have tried to type the contents in this video as part of my reference.  Please check the video link.
1. Inroduction to Scrum
2. Backlog refinement Meeting
3. Sprint Planning Meeting
4. Sprint Planning Meeting
5. Sprint Review Meeting
6. Sprint Retrospective meeting

Introduction to scrum
1. What is Scrum?
Scrum is framework for dealing with complex work such as new product development. It is an alternative to traditional approach that is more suited to manufacting and construction. Why do we need an alternate approach? Earlier the focus was on execution rather than innovation. People with defined roles used defined model, defined best practices to execute the defined plans which did not change very quickly. It was predictable since we knew what we were trying to accomplish, how we will accomplish it.

Today a lot of predictable and repeatable work is done much faster often by machines. Things change more quickly. In order to stay competitive we need to inspect, adapt more quickly and deal with greater uncertinity. A transparent framework including time boxed and feedback loops can help us master uncertinity. Only learning organizations will be able to keep  up with the change. Scrum is a framework that is learning about the work and the processes that is used to do it. It is like chaos put inside a box to
address the uncertinity.  It is mostly used to develop software products and may be used for other complex work. Scrum introduces feedback loops encouraging us to examine the product we are building and the processes we use to build that product.

Pradictable(old manufacturing): It is typical to adopt the defined (theorethical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood.

Chaotic (timeboxed)- When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.

Anarchy: usually the old predictable model ends in anarchy

Scrum is associated with Agile movement described as Agile Manefesto. Manifesto for Agile Software development: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
We value Individuals and interactions over processes and tools
                Working Software over comprehenchive documentation
                 Customer collaboration over contract negotiation
                 Responding to changes over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The basic intent of all the agile approach is similar in the sense, we have early and sustainable rate of value feature delivery.  Early in the product development cycle we want to see some features working rather than one huge release in the end. Ideally, we will be able to continue incremental improvements indefinately. Product development is ongoing with frequent releases rather than one shot project.
Scrum is not about the attempt to use the traditional Gantt (Requirement analysis, design, code, integration, test, deploy) ideas for developing software that was once authored by Dr Winston Royce in 1970. He drew a picture showing a series of phases. One phase connected to the next phase and again to the next phase and so on and each one has a hand off.  We do the analysis in the beginning and when done we start the design then write the code then integrate, then test and finally deploy. This could work if we had perfect knowledge in the beginning and never made mistakes along the way or it never changed along the way.
The next sentence in Dr. Winston Royce paper stated that "I believe in this concept but, the implementation described above is risky and invites failure." The reason it fails with the complex work is because we do not have perfect knowledge in the beginning. In fact we know less about the project in the beginning. The plan driven approach requires us to make our most important decisions right after the initiation when we know the least.  Waterfall projects eventually decends in anarchy.When the actual work finally happens, it is with low quality and too much over time.
Scrum is like  adding all those phases in the blender. All the ingredients are mixed into every sprint. Instead of driving the work into different phases, we divide into fixed length iterations called sprints. Every Sprint contains some combination of analysis, design, actual implementation, testing, planning for the future if we will be shipping or deploying more frequently.

Right from the first sprint, scrum team will deliver a working, tested, shippable product increment even if it starts out small. Every sprint they demonstrate what a little bigger shippable increment product to everyone. Customers often needs to see the wrong part for them to specify what they really need.  With short iteration and more feedback, we have a better chance of discovering the right part.  While the product owner does not have to ship every sprint, it is the teams job to make it possible. Sprints
are usually 30 days long and most teams are doing in 2 weeks. To make a shippable product every two weeks, we need people with skills for business requirements, design, coding, testing and they are cross- functional self organizing team. Instead of waiting to test at the end, we start testing increments in the very first sprint. Instead of all the design upfront, we do the incremental design in every spring until it becomes continuous design. We do a small amt of continiuous redesign and refactoring to avoid technical death. Every sprint combines all aspects of the work.  The scrum team should collaborate together instead of working in phases during handoff. Scrum brings challenges to individuals, teams and organizations. If it is not distracting the organization, then we are not doing scrum.  Scrum is hard to practice. The purpose of scrum with strict rules is to reveal organizations impediments that we can start fixing if we have the courage and commitment. It takes courage and commitment. Healing the organizations impediment exposed by trying to use scrum are more important than doing scrum. The path to masterly starts with learning the framework properly.

2. Scrum Elements: Scrum provides a structure of roles, meetings, artifacts. There are only 3 roles as specified by scrum. a. Product  Owner, b. Scrum Master c. Scrum development team.

The product owner is a single individual responsible for Return On Investment (ROI) of product development effort, he has the influence of proritization of product backlog, Final arbiter of requirements questions. It does not mean he will give the details of all the requirements upfront or in detail every sprint, but he does make the final call of those things. Product owner must have the vision behind the product development.  It often does not make sense to make a detailed roadmap when there is uncertinity in the future but a vision is important. The team has to work thro' the product owner to get what they want. He is one person who makes proritization decision for that team.  He makes the business decision for that team, focused  more on the what than on the how.

Scrum development team: It is cross-functional group, they are resposible and  attempt to  build a "potentially shippable product increment" every sprint, they collaborate and are self-oranizing. If we keep the same team together in the right environment full time with effective retrospective sprint after sprint. They may become a learning team building block of the learning organization. There are no exteranally imposed hirarchy or job titles on this team. it opens the leadership to emerge naturally to
control the flow from person to person naturally.  The scrum team is a small group of people, ideally from 4-9 people team ideally feature teams with minimal inter-dependaencies. Team collaboration emerges natually in a team room. If spread in different parts of the world, we may be suffering from collaboration and coordination.
Scrum will quickly bring this problem to the surface. We may experience breakthrough by getting remote people in one room for one or two sprints in the beginning and every few months after that. Information sharing tools help with the practical problem of sharing information. Tools by themselves do not transform organizations.

Scrum Master: Has no management authority, does not have a project manager role and is a facilitator. " If I am your scrum master, you are not my scrum slave." It is just the opposite. Scrum master has no authority over the team. Scrum master is not a project manager. The responsibility of the project manager is split up between the product owner and the team with the scrum master acting like a facilitator. The scrum master protects the team from distractions and interruptions. Gets things done backing natural team organization, removes impediments impacting the team, facilitates the process, teaches how to use scrum, promotes improved engineering practices. Enforces timeboxes, provides visibility, somehow all the above without the authority of a management power.
"Example ScrumMaster Checklist" -(http://www.open.collab.net/media/pdfs/scrummasterchecklist.pdf)"

Artifacts: The two important artifacts are product blacklog and Sprint backlog. The product backlog is a one dimentional list of everything we might ever do.  It is a customer- centric features  proritized by the product owner, it is a list of everthing we might ever do. If it is not in the backlog, it does not exist. Anyone can add items to the product backlog, the product owner has to proritize it, and the scrum master has to make it visible,  A well formed product backlog does not contain task, but has only well formed product backlog items (PBI), which might be in a user- story form or user case scenarios. Forced ranked means there is only one thing in the top position. Getting organizations to do this is a breakthrough.
The sprint backlog is what we have committed to do now. It has an end date and it has the committed backlog items representing the what and the sprint task representing the how (Not started, in progress, completed)

Meetings in scrum: There are 4 meetings in scrum: sprint Planning meeting, Daily scrum, sprint review meeting, and the Sprint retrospective meeting (plus backlog refinement meeting).
Two week sprint (wk 1 M-F and wk 2-M-F)Wk -1 Monday- Sprint planning meeting (4 hours- 9 am to 1 pm), wk 2 Wed Backlog Refinement Meeting ( 2 hours 1-3pm), Sprint review meeting 2nd friday (2 hrs 10-12) noon and again 2nd week Friday (2 hours 1-3pm).
Sprint Planning meeting: The team and the product owner negotiates which items gets the proirity to be committed to the sprint. The teams picks top priority items from the product backlog and commits them to the sprint backlog and makes them into smaller task and decides the right amount of work to do and  if they are clear aboutwhat work to do. They plan one sprint.
During sprint execution, the team meets once per day (15 mins stand up or)the daily scrum meeting, before collaborating the meeting. One official meeting where we stand up and report to each other, not to the scrum master, not to Product owner just to the team what I did yesterday and I am going to do today and what are the impediments. All members of the team give the same report to the rest of the team.

At the Sprint review meeting, the team demonstrates a potentially shippable increment to the product owner, and anyone else who may be interested like stakeholders. Product owner will declare which items are done, which items did not meet the requirements (potential shippable increment), measure velocity and get feedback from stakeholders as to how we are doing with them. A lot of time the feedback is you did what you said you will do or we realize that we need something else. We could not have known that until we saw the functioning product increment(wrong product increment.) So, it is during the sprint review meetings we get a lot of feedbacks of the product against requirements.
Every sprint ends with sprint retrospective meeting for the team to inspect the wrong process. The way we inspect and adapt the way we worked together in the last iteration.  We talk about what went well, what could be improved, what we learnt, what puzzles us. We give feedback to each other.  These things comes out in retrospective  are improvement of techniques.  The team takes ownership to their process. Regular retrospective meetings provide regular feedback to the process and the team uses to build the process.
Backlog refinement meeting: the team and the product owner get together and decide on the product backlog items for the next couple of sprint. they clarify them, group the big product backlog items or epics into smaller tasks or split them into user stories so that they can do a few of them in a sprint. They get input about proritization,dependancy. Also found in sprint meeting, but people prefer to do it in a seperate meetings.
To learn about sprint, download
Scrum Reference Card, Example Scrummaster's checklist

Notes from Video.

ITIL benefits

Key Benefits of ITIL

ITIL in summary ebook

ITIL in 30 seconds  (Copied from the link incase if there is an issue with the link) Sharing something I came across.

What is ITIL?ITIL is a set of concepts and guidelines that focuses on managing IT services.
It’s part of a wider IT service management discipline that aims to achieve greater
customer satisfaction by putting more focus on the customer and a larger
emphasis on internal and external communication.

The ITIL Breakdown

Among other things, ITIL is broken down into 4 main processes: Incident, Problem, Change and Release Management. These all interrelate to each other and focus on the dealing with customers, documenting known issues, managing change and releasing new changes to a production environment.
Many small- to medium-sized companies are put off by ITIL’s apparent complexity. This shouldn’t be the case. ITIL simply boils down to an effective way to manage deadlines, priorities and service-level agreements.

Incidents
An incident is a single event, a disruption or query that negatively affects the quality of a service to a customer. It will have a time frame in which it needs to be resolved. The focus of incident management is about getting your customers up and running by whatever means necessary. Successfully managing incidents means the right priority is assigned, appropriate deadlines are in place and there’s transparent communication and understanding of the incident’s context and who or what it affects. It allows you to accurately measure your Service Level Agreement compliance and understand your incident hot spots and their wider impacts.

Problems
A problem is a flaw that affects the quality of a service. By definition, a problem is at the root of every incident; an underlying issue with a service that needs a short-term workaround (to minimize disruption when it occurs) and long-term solution (so that it doesn’t happen again).
Problem management is a proactive way of managing your services. It’s about knowing what flaws exist in your system, offering quick workarounds for when they occur and, if warranted, investigating long-term solutions.

Changes
A release has a prepared and tested set of components, an agreed time frame to release these changes and a record of every deployment. Release management focuses on communicating clear points of impact, ensuring quality of the production environment and minimizing any customer facing disruptions. Effective release management allows you to deliver change more efficiently, at
optimal cost and at reduced risk. It affords you greater confidence in your release process.

Releases
Releases can be made up of many Changes. Underneath the processes sits Configuration and Knowledge. These are the central repositories for your company’s data, information
and knowledge. Configuration management focuses on infrastructure and deals with identifying,
defining and mapping your assets and their relationship to one another (an asset can be a piece of software, hardware, a company, person or location). Knowledge management complements this with a focus on service-related information, processes and initiatives.

Configuration and Knowledge:Both Configuration and Knowledge can cause, relate to, or aid in the
management of incidents, problems, changes and releases.

CONFIGURATION KNOWLEDGE:
Underneath the aforementioned processes sits Configuration and Knowledge. These are the central repositories for your company’s data, information and knowledge.
Configuration management focuses on infrastructure and deals with identifying, defining and mapping your assets and their relationship to one another (an asset can be a piece of software, hardware, a company, person or location). Knowledge management complements this with a focus on service-related information, processes and initiatives.

Taken from the following source:
www.gotoassist.com
Email: support@gotoassist.com
Twitter: @gotoassist
Blog: blog.gotoassist.com
Community: itpros.community.gotoassist.com/gotoassist

Further Reading
If you’re interested in more ITIL resources, check out: www.itil-officialsite.com for
more information on ITIL qualifications and publications http://www.itsmfusa.org
for more information about the ITIL community, local events and resources.© 2013 Citrix Online, LLC. All rights reserved. Citrix, GoToAssist,