What is Scrum?
Scrum is a popular project management framework that uses an iterative and incremental methodology in Agile Software Development.
Do you know what the word scrum really mean? Here is a quote from a dictionary:
Scrum – an ordered formation of players, used to restart play, in which the forwards of a team form up with arms interlocked and heads down, and push forward against a similar group from the opposing side…
Today, most technology related projects are moving from the traditional Waterfall development framework to an Agile development framework like Scrum. As technology are fast changing and it becomes necessary to deliver incrementally and better the ability to adapt to changes, which will almost always happen.
Lots of projects are said to be doing Scrum, but do they really understand the guiding principal behind Scrum? I will try to summarize the key aspects below in a page, it is not meant to be the extensive list of everything about Scrum.
- Responsible for the product vision and maximizing the (ROI) return on investment of the development effort to best reward of all stakeholder interests.
- Define Product Backlog, prioritization, and arbiter for any requirement questions.
- Accepts or rejects each product increment.
- Approves product deployment and any decision to continue product development.
Scrum Development Team
- he team should be relatively small, best with 7 to 10 people. They need to be highly collaborative and always have access to communicate with each other. Some prefer to be in the same location and the same room, but with today’s collaboration tool, a virtual team room can also be very effective.
- Cross-functional team, includes members with various skill sets needed for the project. In addition to the traditional developers, the team should include business analysts, domain experts, testing skills, … etc.
- The team should be self-organizing and self-managing. Basically all individuals work together and are responsible toward the same goal.
- Negotiate commitments for each Sprint with the Product Owner and has autonomy regarding how to reach commitments.
- Facilitates the Scrum process, enforces timeboxes, and organizes all the artifacts.
- Captures empirical data and leverage them to improve accuracy of project forecasts.
- Be the external communication point person, shields the team from external distractions to preserve the team’s focus and helps to resolve any impediments.
- Promotes improved processes but has no management authority over the team.
Sprint Planning Meeting – occurs at the beginning of each Sprint between the Product Owner and the team to negotiate which Product Backlog Items to include and commit to.
Daily Scrum – a daily 15 minutes scrum for the team to report to each other, summarizing what he did the previous day, what he will do today, and impediments if any. This should NOT be a deep design or troubleshooting session. It meant to be a status meeting and allowing the team to gain transparency on each other’s progress.
Sprint Review Meeting – After each Sprint execution, the team should hold a review meeting to demonstrate a working project to the Product Owner and other users. After the meeting, the Product Owner will declare if he/she will accept the deliverable and signoff. In case if any item considered incomplete, it will be returned to the Product Backlog.
Sprint Retrospective Meeting – each Sprint should ends with a retrospective meeting. Allowing the team to reflect on its own behavior and process and take action to improve for future Sprints. It is important to provide a safe and open atmosphere for the team to speak freely, so presence of people who conduct performance appraisals or immediate managers can be impediment to this process.
Backlog Refinement Meeting – this is an ongoing meeting that between the Product Owner and the team to better understand the Product Backlog Items (PBIs) and refine them both for definition and technology concerns. A well define list of PBIs and priority will help to stream line the Sprint Planning Meeting.
Burn Down Chart
A burn down chart highlight the ideal tasks remaining timeline vs the actual tasks remaining timeline. It provide a good summary of how your project is trending. Is it on schedule, falling behind, or ahead of schedule? This is a very powerful tool, although the challenge to produce a good chart on this relies heavily on a set of good and up-to-date underlying data.
The ideal tasks remaining timeline – is the the total workload minus the expected work done, usually calculated based on work estimate divided over a time period. This tend to be a straight line as it is trying to divide the work equally over time.
The actual tasks remaining timeline – is the total workload minus the actual work done, this is the line that will tell you how your project is actually trending.
Base on the above illustration:
Whenever the red line is above the blue line give you an indication that your project maybe behind schedule and you should review resource allocation and their performance.
Whenever the red line is below the blueline gives an indication that your project is ahead of schedule, and you may want to reallocate some of the resource to do other things.
Other Scrum Artifacts
Product Backlog – a prioritized list of desired functionality.
Product Backlog Item – Specifies a customer-centric feature, focus on what it is.
Sprint Backlog – Consists of all committed PBIs.
Sprint Task – Specifies how to achieve the PBIs.
8,067 total views, 5 views today