2015-(4) past paper questions with answers
Questions
- State what is Scrum framework.
- Justify the importance of Scrum Master role.
- Scrum framework proposes different kinds of meetings.
- List all five types of meetings.
- Describe three of them in detail. The description must include the following facts:when, why, how and by whom.
- Scrum also produces many artifacts.
- List five of them.
- Describe briefly about three of such artifacts.
- Prove that scrum is an Agile process.
Answers
- Scrum is a management framework for incremental product development using one or more cross-functional, self-organizing teams of about seven people each. It provides a structure of roles, meetings, rules, and artifacts. Scrum uses fixed-length iterations, called Sprints, which are typically two weeks or 30 days long.
- Scrum Master Facilitates the following things in scrum meeting so scrum master role is important
- Facilitates the Scrum process
- Helps resolve impediments
- Creates an environment conducive to team self-organization
- Captures empirical data to adjust forecasts
- Shields the team from external interference and distractions to keep it in group flow
- Enforces time boxes
- Keeps Scrum artifacts visible
- Promotes improved engineering practices
- Has no management authority over the team (anyone with authority over the team is by definition not its Scrum Master)
- Meetings
- Different kinds of meeting in scrum
- Scrum meeting
- Sprint planning meeting
- Sprint review meeting
- Sprint Retrospective Meeting
- Backlog Refinement Meeting
- Describe meeting in detail
- Scrum meeting
- In Scrum, on each day of a sprint, the team holds a daily scrum meeting called the "daily scrum.” Meetings are typically held in the same location and at the same time each day. Ideally, a daily scrum meeting is held in the morning, as it helps set the context for the coming day's work. Scrum Meetings are facilitated by the Scrum Master, who has no decision-making authority at these meetings.
- Sprint planning meeting
- Product Owner and team hold a Sprint Planning Meeting to negotiate which Product Backlog Items they will attempt to convert to working product during the Sprint. he Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement without accruing technical debt. The team “pulls” work from the Product Backlog to the Sprint Backlog.
- Sprint review meeting
- To demonstrate a working product increment to the Product Owner and everyone else who is interested. The meeting should feature a live demonstration. Incomplete items are returned to the Product Backlog and ranked according to the Product Owner’s revised priorities as candidates for future Sprints.The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.
- Sprint retrospective meeting
- Each Sprint ends with a retrospective. At this meeting, the team reflects on its own process. They inspect their behavior and take action to adapt it for future Sprints. Dedicated Scrum Masters will find alternatives to the stale, fearful meetings everyone has come to expect. An in-depth retrospective requires an environment of psychological safety not found in most organizations.
- Backlog refinement meeting
- The team estimates the amount of effort they would expend to complete items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.a subset of the team, in conjunction with the Product Owner and other stakeholders, will compose and split Product Backlog Items before involving the entire team in estimation.
- Artifacts
- List of artifacts
- Product backlog
- Product backlog item (PBI)
- Sprint backlog
- Sprint task
- Sprint burndown chart
- Product/release burndown chart
- Describe in detail
- Product backlog
- Force-ranked list of desired functionality
- Visible to all stakeholders
- Any stakeholder can add items
- Constantly re-prioritized by the Product Owner
- Items at top are more granular than items at bottom
- Maintained during the Backlog Refinement Meeting
- Product Backlog Item (PBI)
- Specifies the what more than the how of a customer centric feature
- Often written in User Story form
- Has a product-wide definition of done to prevent technical debt
- May have item-specific acceptance criteria
- Effort is estimated by the team.
- Sprint Backlog
- Consists of committed PBIs negotiated between the team and the Product Owner during the Sprint Planning Meeting
- Scope commitment is fixed during Sprint Execution
- Initial tasks are identified by the team during Sprint Planning Meeting
- Team will discover additional tasks needed to meet the fixed scope commitment during Sprint execution
- Visible to the team
- Referenced during the Daily Scrum Meeting.
- Sprint Task
- Specifies how to achieve the PBI’s what
- Requires one day or less of work
- Remaining effort is re-estimated daily, typically in hours
- During Sprint Execution, a point person may volunteer to be primarily responsible for a task
- Owned by the entire team; collaboration is expected
- Sprint Burndown Chart
- Indicates total remaining team task hours within one Sprint
- Re-estimated daily, thus may go up before going down
- Intended to facilitate team self-organization.
- Fancy variations, such as itemizing by point person or adding trend lines, tend to reduce effectiveness at encouraging collaboration
- Seemed like a good idea in the early days of Scrum, but in practice has often been misused as a management report, inviting intervention.
- The Scrum Master should discontinue use of this chart if it becomes an impediment to team self-organization.
- Product / Release Burndown Chart
- Tracks the remaining Product Backlog effort from one Sprint to the next
- May use relative units such as Story Points for Y axis
- Depicts historical trends to adjust forecasts