Scrum Teminology

The resources available for Scrum is huge in web. Here I gonna to summarize them.

Agile : an confusing word

Agile is a general term that is used to cover numerous methodologies of software development like DSDM [Dynamic system development], Extreme programming, Scrum etc. Each of these methodologies has its own terminology but all of them have a same philosophy.

Agile project management philosophy, though not very different from the traditional management practices and framework, needs to be rationalized to suit the demands of the agile methodologies. The project management practice remains the same for gathering requirements, planning, initiating and tracking the progress of the project in line with the business vision, but the focus is more on adaptability towards changing requirements, team work, collaboration and the ability to plan and deliver small chunks of usable software in short intervals of time.
So it is noticeable that the general practices of software development process remain same and an Agile team should know how to gather requirements, how to apply patterns, how to design and so on. But team is forced to promise and suppose following materilas:

1. The team should consider that the rate of changes in requirements is high. So no objection is acceptable towards instability of requirements.
changes is a fact not exception

2. The team should have a presentable product every time after after initial development phase of project. Scrum has frequent intermediate deliveries with working functionality, like all other forms of agile software processes. This enables the customer to get working software earlier and enables the project to change its requirements according to changing needs.

3. Customers become a part of the development team (i.e., the customer must be genuinely interested in the output.)

4. Frequent risk and mitigation plans are developed by the development team itself—risk mitigation, monitoring and management (risk analysis) occurs at every stage and with commitment.

5. Frequent stakeholder meetings to monitor progress—balanced dashboard updates (delivery, customer, employee, process, stakeholders)

6. Workplaces and working hours must be energized—"Working more hours" does not necessarily mean "producing more output."

So, how to design a process for software development which satisfy the mentioned requirements?

I am not going to answer this question since the response is clear. Instead I talk about the roles, artifacts in the Scrum. In the following post which be alloted for best practices I will refer to this terms frequently. Please note that Scrum focuses more on management issues and assumes that the best practices of Agile such as Refactoring, Continuous Integration, Test Driven Development, User story writing and so on are indistinguishable parts of team. In other words assuming best practices, Scrum recommends solutions for project managements. Unfortunately some people think that best practices are not important part of Scrum but I would like emphasis that they are preliminary facts which are should be considered before applying Scrum. Following materials are adopted from http://en.wikipedia.org/wiki/Scrum_(development) and other resources from web.

1) Roles

Product Owner

The Product Owner represents the voice of the customer. He/she ensures that the Scrum Team works with the "right things" from a business perspective. The Product Owner writes customer-centric items (typically user stories), prioritizes them and then places them in the product backlog.

ScrumMaster (or Facilitator)

Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster's role is to protect the team and keep them focused on the tasks in hand. The ScrumMaster is NOT responsible for the transition from traditional methods of working to Scrum or the implementation of Scrum. .

Team

The team has the responsibility to deliver the product. A team is typically made up of 5–9 people with cross-functional skills who do the actual work (design, develop, test, technical communication, etc.).

Stakeholders (customers, vendors)

These are the people who enable the project and for whom the project will produce the agreed-upon benefit[s], which justify its production. They are only directly involved in the process during the sprint reviews.

Managers

People who will set up the environment for the product development organizations.

2) Meetings

Daily Scrum

Each day during the sprint, a project status meeting occurs. This is called a "daily scrum", or "the daily standup".

Scrum of scrums

Each day normally after the daily scrum.

• These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.
• A designated person from each team attends.

The agenda will be the same as the Daily Scrum, plus the following four questions:^[7]

• What has your team done since we last met?
• What will your team do before we meet again?
• Is anything slowing your team down or getting in their way?
• Are you about to put something in another team’s way?

Sprint Planning Meeting

At the beginning of the sprint cycle (every 15–30 days), a "Sprint Planning Meeting" is held.

• Select what work is to be done
• Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team
• Identify and communicate how much of the work is likely to be done during the current sprint
• Eight hour limit

At the end of a sprint cycle, two meetings are held: the "Sprint Review Meeting" and the "Sprint Retrospective "

Sprint Review Meeting

• Review the work that was completed and not completed
• Present the completed work to the stakeholders (a.k.a. "the demo")
• Incomplete work cannot be demonstrated
• Four hour time limit

Sprint Retrospective

• All team members reflect on the past sprint.
• Make continuous process improvement.
• Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
• Three hour time limit

3) Artifacts

Product backlog

The product backlog is a high-level document for the entire project. It contains backlog items: broad descriptions of all required features, wish-list items, etc. prioritized by business value. It is the "What" that will be built. It is open and editable by anyone and contains rough estimates of both business value and development effort. Those estimates help the Product Owner to gauge the timeline and, to a limited extent, priority. For example, if the "add spellcheck" and "add table support" features have the same business value, the one with the smallest development effort will probably have higher priority, because the ROI is higher.

The product backlog is property of the Product Owner. Business value is set by the Product Owner. Development effort is set by the Team.

Sprint backlog

The sprint backlog is a document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks; as a best practice tasks are normally estimated between four and sixteen hours of work. With this level of detail the whole team understands exactly what to do, and anyone can potentially pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills.

The sprint backlog is property of the Team. Estimations are set by the Team. Often an according Task Board is used to see and change the state of the tasks of the current sprint, like "to do", "in progress" and "done".

Burn down Chart

The Sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. There are also other types of burndown, for example the Release Burndown Chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple iterations) and the Alternative Release Burndown Chart, which basically does the same, but allows to show clearly scope changes into a Release Content, by resetting the baseline.

It should not be confused with an earned value chart.

4) Other

Impediment

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

Sprint

A time period (typically between two weeks and one month) in which development occurs on a set of backlog items that the Team has committed to.

Sashimi

A slice of the whole equivalent in content to all other slices of the whole. For the Daily Scrum, the slice of sashimi is a report that something is done.

Velocity

How much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning.

Abnormal Termination

The team can cancel a Sprint if they feel they are unable to meet the Sprint Goal. Management can cancel a Sprint if external circumstances negate the value of the Sprint Goal. If a Sprint is abnormally terminated, the next step is to conduct a new Sprint planning meeting, where the reason for the termination is reviewed.