This note is protected by password and is a Read Only.

What's so special about scrum?



With scrum, the product is built in a series of fixed-length iterations called sprints that give teams a framework for shipping software on a regular cadence. Milestones–i.e., the end of a sprint–come frequently, bringing with them a feeling of tangible progress with each cycle that focuses and energizes everyone. ("Continuous inspiration" for the win!) Short iterations also reinforce the importance of good estimation and fast feedback from tests–both recurring struggles in waterfall projects.

Scrum calls for four ceremonies that bring structure to each sprint:
  • Sprint planning: A team planning meeting that determines what to complete in the coming sprint.
  • Daily stand-up: Also known as a daily scrum, a 15-minute mini-meeting for the software team to sync.
  • Sprint demo: A sharing meeting where the team shows what they've shipped in that sprint.
  • Sprint retrospective: A review of what did and didn't go well with actions to make the next sprint better.
During a sprint, visual artifacts like task boards and burndown charts, visible to the team and spectators alike, are powerful motivators. They drive a spirit of "we're doing this!" Having the opportunity to show off new work at the sprint demo is equally motivating, and the consistent, incremental feedback the team gets from stakeholders at each demo creates a powerful way to develop products.

Scrum done well–which is to say, not "waterfall with stand-ups"–can be a massive catalyst for improving team productivity and morale, and the product development process as a whole.

Three essential roles for scrum success



A scrum team has a slightly different composition than a traditional waterfall project, with three specific roles: product owner, scrum master, and the development team. And because scrum teams are cross-functional, "the development team" includes testers, designers, and ops engineers in addition to developers.

The product owner


Product owners are the champions for their product. They are focused on understanding business and market requirements, then prioritizing the work to be done by the engineering team accordingly. Effective product owners:
  • Help build and manage the product backlog
  • Closely partner with the business and the team to ensure everyone understands the work items in the product backlog
  • Give the team clear guidance on which features to deliver next
  • Decide when to ship the product with the predisposition towards more frequent delivery
Keep in mind that a product owner is not a project manager. Product owners are not managing the status of the program. They focus on ensuring the development team delivers the most value to the business. Also, it's important that the product owner be an individual. No development team wants mixed guidance from multiple product owners.

The scrum master


Scrum masters are the champion for scrum within their team. They coach the team, the product owner, and the business on the scrum process and look for ways to fine-tune their practice of it. An effective scrum master deeply understands the work being done by the team and can help the team optimize their delivery flow. As the facilitator-in-chief, they schedule the needed resources (both human and logistical) for sprint planning, stand-up, sprint review, and the sprint retrospective.

Scrum masters also look to resolve impediments and distractions for the development team, insulating them from external disruptions whenever possible.

Part of the scrum master's job is to defend against an anti-pattern common among teams new to scrum: changing the sprint's scope after it has already begun. Product owners will sometimes ask, "Can't we get this one more super-important little thing into this sprint?" But keeping scope air tight reinforces good estimation and product planning–not to mention fends off a source of disruption to the development team.

Scrum masters are commonly mistaken for project managers, when in fact, project managers don't really have a place in the scrum methodology. A scrum team controls its own destiny and self-organizes around their work. Agile teams use pull models where the team pulls a certain amount of work off the backlog and commits to completing it that sprint, which is very effective in maintaining quality and ensuring optimum performance of the team over the long-term. Neither scrum masters nor project managers nor product owners push work to the team (which, by contrast, tends to erode both quality and morale).

The scrum team


Scrum teams are the champions for sustainable development practices. The most effective scrum teams are tight-knit, co-located, and usually 5 to 7 members. Team members have differing skill sets, and cross-train each other so no one person becomes a bottleneck in the delivery of work. Strong scrum teams approach their project with a clear "we" attitude. All members of the team help one another to ensure a successful sprint completion.

As mentioned above, the scrum team drives the plan for each sprint. They forecast how much work they believe they can complete over the iteration using their historical velocity as a guide. Keeping the iteration length fixed gives the development team important feedback on their estimation and delivery process, which in turn makes their forecasts increasingly accurate over time.

Ceremonies



Meetings, or "ceremonies" are an important part of agile development. But they are one of many important elements, and shouldn’t be conducted in a vacuum. (It's tempting to add some ceremonies to a waterfall project and call it "agile", but this will get you nowhere.)

Let's take a look at each of the agile ceremonies, and understand how they empower the team and drive agile development.

Note: A number of these ceremonies come from the practice of scrum which is an iterative, time-boxed approach to implementing agile. The concepts behind these ceremonies can be applied to other forms of agile like kanban or lean. "Sprint" is a scrum-specific term. Other forms of agile use the more generic term "iteration" to indicate a time-boxed period of development.

Sprint planning


Attendees Required: development team, scrum master, product owner

When: At the beginning of a sprint.

Duration: Usually an hour per week of iteration–e.g. a two-week sprint kicks off with a two-hour planning meeting.

Purpose: Sprint planning sets up the entire team for success throughout the sprint. Coming into the meeting, the product owner will have a prioritized product backlog. They discuss each item with the development team, and the group collectively estimates the effort involved. The development team will then make a sprint forecast outlining how much work the team can complete from the product backlog. That body of work then becomes the sprint backlog.

ProTip: Use the sprint planning meeting to flesh out intimate details of the work that needs to get done. Encourage team members to sketch out tasks for all stories, bugs, and tasks that come into the sprint. Foster discussions and gather consensus on the plan of action. Effective planning significantly increases the team's chances of success meeting the commitments of the sprint.

Daily stand-up



Attendees Required: development team, scrum master, product owner
Optional: team stakeholders

When: Once per day, typically in the morning.

Duration: No more than 15 minutes. Don't book a conference room and conduct the stand up sitting down. Standing up helps keep the meeting short!

Purpose: Stand-up is designed to quickly inform everyone of what's going on across the team. It's not a detailed status meeting. The tone should be light and fun, but informative. Have each team member answer the following questions:
  • What did I complete yesterday?
  • What will I work on today?
  • Am I blocked by anything?
There's an implicit accountability in reporting what work you completed yesterday in front of your peers. No one wants to be the team member who is constantly doing the same thing and not making progress.

ProTip: Some teams use timers to keep everyone on track. Others toss a ball across the team to make sure everyone's paying attention. Many distributed teams use videoconferencing or group chat to close the distance gap. Your team is unique. Your stand up should be, too!

Iteration review


Attendees Required: development team, scrum master, product owner
Optional: project stakeholders

When: At the end of a sprint or milestone.

Duration: 30-60 minutes.

Purpose: Iteration review is a time to showcase the work of the team. They can be in a casual format like "demo Fridays", or in a more formal meeting structure. This is the time for the team to celebrate their accomplishments, demonstrate work finished within the iteration, and get immediate feedback from project stakeholders. Remember, work should be fully demonstrable and meet the team's quality bar to be considered complete and ready to showcase in the review.

ProTip: We take a casual approach to sprint reviews and give them a celebratory feel. We gather around a team member's desk and watch them demo their new feature. It's not uncommon to hear clapping throughout the office!

Retrospective


Attendees Required: development team, scrum master, product owner

When: At the end of an iteration.

Duration: 60 minutes.

Purpose: Agile is about getting rapid feedback to make the product and development culture better. Retrospectives help the team understand what worked well–and what didn't.

Retrospectives aren't just a time for complaints without action. Use retrospectives to find out what's working so the team can continue to focus on those areas. Also, find out what's not working and use the time to find creative solutions and develop an action plan. Continuous improvement is what sustains and drives development within an agile team, and retrospectives are a key part of that.

ProTip: Even if things are going well across the team, don't stop doing retrospectives. Retrospectives provide ongoing guidance for the team to keep things going well.
Some people think agile ceremonies magically make a team agile. They're wrong.
A team's agility is built on solid engineering practices, a tactical and strategic approach to change, and great team collaboration. Agile ceremonies simply facilitate communication across the team.

None Private Note List:

URL Note Summary Days before delete
AllowedHtml <ul> <li><br> - Line break.</li> <li><o... 30137
BigDataFishig <b>#RealTimeData + #BigData + #Fishing</b>...teach... 30975
ChatSample Lee: Hello there, so can you explain how to chat u... 30137
Command-Line-Shortcuts <h3>Basic Keyboard Shortcuts</h3><b>Up/Down Arrows... 30223
dba <h2 style="display: inline;">Timeline:</h2> 21-Ja... 30166
dst_upgrade <h1>Oracle 11.2.0.2 DST Upgrade</h1><ol><li><b>che... 30201
Feedback ... 30081
hadoop_class_at_ebay eBay's North Campus, Parley room 2161 N. First ... 30260
mysql Get the size of a MYSQL Dababase: [code]SELECT ta... 30136
outlook-meeting-assassin <h1>Outlook Meeting Assassin</h1>A Simple Outlook ... 30695
Programming-Quotes <h3>Programming Quotes</h3> “ Java is to JavaScri... 30223
scrum <h2 style="margin: 0px 0px 0px 0px; padding: 0px 0... 867
vi <h2>vi cheat sheet</h2><b><u>Starting & ending com... 30142
websiteTricks-transperent [code]<!-- div.background { width:500px; h... 30081
xdb_installation <h1>Oracle XML DB (XDB) Installation</h1><ol> <li... 30201
zzzzzzzzzzz whycghkghfjjfhkctshsaqzmypqgrehghtmfggfhgoygvfjknm... 652

What else can I do with this?