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, 

ITIL in a nutshell

Please note: Please click on the topic link for the source of the definition and/or sample example for further reading.

1. Introduction to ITSM
   IT Service Lifecycle Management: The figure below represents the five domains of ITIL’s IT Service Lifecycle along with the people, process and products required to make each domain fulfill its ‘silo of purpose’ within the IT organization.
   
   • IT's Total Cost of Ownership (TCO): Total Cost of Ownership (TCO) is an analysis meant to uncover all the lifetime costs that follow from owning certain kinds of assets. Ownership brings purchase costs, of course, but ownership can also bring costs for installing, deploying, operating, upgrading, and maintaining the same assets.
   • ITSM's Value to the Business: To improve its IT organization, ITIL consists of an inter-related set of best practices for improving the quality of IT services delivered to users.
   • The Benefits Of ITIL: Key Benefits of ITIL:
   • What you can learn:
   • -Manage business risk for your services by using ITIL availability management, capacity management, IT service continuity management, information security management and seven-step improvement processes to identify, prioritize and manage service improvement opportunities.
   • -Minimize service disruption by using the ITIL incident management and problem management processes to swiftly restore services, develop effective workarounds, run blameless major incident reviews, investigate and eliminate root causes, and prevent incidents from reoccurring.
   • -Quantify and clearly demonstrate the true value of the services you provide by using the ITIL financial management process to deliver the required financial stewardship and show improved governance over investments. 
   • -Benchmark services and maximize return on investment by using the ITIL service portfolio management process to map customer requirements against the investments required to build and deliver the services your customers need, at the right cost and quality. 
   • -Obtain value for money from your service providers by using the ITIL supplier management process to measure and manage supplier performance and ensure contracts with suppliers are optimized to support your agreements with your customers.
   • -Support the marketing and consumption of your services by using the ITIL service catalogue management process to improve communications, streamline the request process and help your customers to understand and link the services you provide to business outcomes they care about
   • What you can achieve:
   • -Ensure the quality of services matches customer needs and expectations by using the ITIL service level management process to define and agree specific and measurable service targets, understand how to best set up monitoring, measuring and reporting, and help identify corrective action opportunities. 
   • -Ensure your customers can use the services when and where needed by using the ITIL availability management process to plan service resilience
   • and recovery, analyze issues involving service unavailability, and drive continual service improvement. 
   • -Ensure the business and your customers are not affected by unexpected service failures by using the ITIL IT service continuity management process to align service continuity plans with business continuity plans, reduce risks to service levels and implement a tested service recovery strategy to meet customer requirements.
   • -Forecast, respond to and influence the demand for your services in a cost effective way by using ITIL demand management and capacity management techniques such as user profiling, modelling, off-peak pricing and differentiated service levels to provide optimal level of capacity and successfully manage fluctuating demand situations.
   • -Support business change at the speed your customer needs while ensuring stable and low-risk environment by using the ITIL change management process to respond to changing requirements in an agile manner whilst optimizing business risk and minimizing the severity of any disruptions to customer’s business processes. 
   • -Build and maintain positive business relationships with customers and improve customer satisfaction by using ITIL business relationship management and service level management processes to find the best practices to enable your teams to better understand and manage customer expectations.
   • IT Service Management (ITSM):The implementation and management of quality IT services that meet the needs of the business. IT service management is performed by IT service providers through an appropriate mix of people, process and information technology. 
   • Critical Success Factors (CSF): The Critical Success Factors (CSFs) are needed for a Process, Project, Plan, or IT Service to succeed:Strong leadership is essential- Have a dedicated, trained and committed process ownerExisting IT environment needs mature assessmentThere should be well defined implementation & continuous service improvement planThere should be clearly defined roles & responsibilities- Responsibility-Accountability-AuthorityClear defined goals & objectives-Specific, Measurable, achievable, realistic & timelyKey performance indicators & metrics-measure achievement of Continual Service Improvement goalsControlling ChangesMaking Quick And Accurate Changes Based On Business PrioritiesProtecting Services When Making ChangesNeed to Know ITSM ConceptsIT Service Provider ModelIT Service Provider Domain Map
   • IT Governance: IT governance (ITG) is defined as the processes that ensure the effective and efficient use of IT in enabling an organization to achieve its goals.
   • IT Resource Management
   • IT Quality Management
   • IT Security Management
   • IT Service Provider Capability Model
   • The Service Provider Model Deployed
   • Good Practice
   • Service
   • Function-Process-Role
2. Introduction to ITIL Version 3
   • ITIL History
   • ITIL Description
   • ITIL v3 Service Lifecycle
   • ITIL v3 Service Lifecycle Management Processes
   • Managing Services with ITIL
3. Service Strategy
   • The Service Lifecycle
   • Service Strategy Objective
   • Service Strategy Processes
   • Service Stategy - Principles
   • Value Creation
   • Utitlity & Warranty
   • Service Assets
   • Service Provider Types
   • Service Portfolio
   • Service Portfolio Management
4. Service Design
   • The Service Lifecycle
   • ITSM Service Design Objective
   • Service Design Processes
   • Service Design Principles
   • Service Portfolio Design
   • Technology Design
   • Process Design
   • Measurement Design
   • Service Provider Models
5. Service Transition
   • The Service Lifecycle
   • Service Transition Objective
   • Service Transition Processes
   • Service Transition Goals
   • Service Transition Value to the Business
6. Service Operation
   • The Service Lifecycle
   • Service Operation Objective
   • Service Operation Processes
   • Service Operation Technology Domains
   • Service Operation Management Domains
   • Service Operation Goals
   • Service Operation Principles
   • Service Operation Value to the Business
7. Continual Service Improvement
   • The Service Lifecycle
   • CSI Objective
   • CSI Model
   • CSI Goal
   • The Principles of CSI
   • CSI Benchmarks
   • Ownership
   • Drivers
   • Service Level Management
   • Continual Improvement
   • Service Measuring & Reporting Frameworks

23 itil v3 foundation

What is ITIL?

What is ITIL?