Scrum is considered to be a lightweight process, but highly prescriptive, and I think that's true. If we take a look here, we can see that there's not a lot of complexity. We can see there are definite pillars, definite artifacts, and definite roles. If we just discussed the roles here, we have the product owner. The product owner represents the customer. The product owner also owns an artifact called the product backlog. The product backlog, sometimes it's called a wish list. It is as close as we can get to a requirements document. In Scrum, there is no traditional requirements document, and a lot of people think that's a good thing. But the product backlog is a set of features, functionalities, capabilities. It's essentially a listing of what are the features or the functionality of the product we're building? What makes it great, and it's prioritized and continuously analyzed. The team actually builds those features that are in the product backlog. We break them down to small tasks called user-stories, and the team builds those user stories. The Scrum Master is the facilitator of the process. We're going to discuss the process. Scrum master is a coach, quite often he or she is a facilitator, a leader, but quite often a servant as well. Then there is the scrum team. The scrum team actually does the work of the product backlog. Those are our developers, testers, designers, business analysts, maybe some documenters. We build the scrum team for the mission that we are on. Then we also have customers, stakeholders, or representatives of customers, and the scrum roles promote the pillars and each role fosters them in the various degrees throughout the sprint. This is a sprint right here, sometimes called an iteration. Quite often, they are documented as two weeks, and that's a pretty typical sprint. The team views and analyzes the backlog and then comes up with a sprint plan or sprint backlogs, and notice these tasks have come off the product backlog, they're quite small, because sprint is a relatively small time-box where the team will eventually build a potentially shippable product increment or solution. If you remember back from the Agile Manifesto, we talked about a working solution. When it says here, potentially shippable, that's how the team should think, this is going to be a working solution, and maybe not the first one or the second one, but very relatively soon, the team can ship this to a customer to begin using it. Some of the artifacts we just talked about are the backlog metrics. Also, there are meetings, there are daily stand-up meetings, sprint reviews, and sprint retrospective and sprint plannings. We can have other meetings besides these, but these are the scrum meetings. Daily stand up obviously happens every day. Sprint review happens at the end of the sprint and that's where we actually view or demo the product that we just built, the product increment, to ourselves. Then we have a sprint retrospective. That's where we look for opportunities for improvement. Both of these happen at the end of the sprint. The sprint planning meeting happens at the beginning. That's where we come up with the sprint backlog or sprint plan.
