Scrum and Scrum Techniques - bounswe/bounswe2016group12 GitHub Wiki

Why Scrum

Backlog

Product Backlog

Product Backlog is basically collection of all user stories, bugs, technical works ,cases, any other requirements collected from customers, executives, even other members for a specific product. Until release planning starts, no filtering and prioritizing processes are implemented. Also Product Backlog ensures the development team has work that maximizes business benefit to the product owner.

Release Backlog

After release planning starts, features would make the product great are selected and the selected ones are prioritized. Then amount of working hours are put for each selected one based on estimation. Sometimes larger tasks are in Release Backlog can be divided into smaller manageable tasks. There are many techniques for estimation. For example, Story Points approach where estimates are made relative to build a small component with a known level of difficulty. However, one question is unanswered with that approach. When the product will be shipped? The approach that answers the question is estimating work in hours. There are some methodologies while using that approach. For instance, tasks that take less than a day can be estimated as 3 hours, 6 hours and 12 hours. If a sample task is 2 hours, it can be labeled as 3 hours. However, if a task is 8 hours, it is labeled as 12 hours estimate. That estimation method is also valid for days. Again, all estimates in between is labeled with larger number. After implementing estimation methologies, set of user stories are ready for Sprint.

Meeting

Burndown Chart

Burndown chart graphically shows how much works left to do for given time. burndown chart

General speaking the Burndown chart should consist of:

  • X axis to display working days
  • Y axis to display remaining work-time
  • Ideal work-time as a guideline
  • Real progress of work.

Comparing Ideal work-time with real progress we can measure performance. This will help group to adjust itself to get everything back on-track. Looking at burndown chart group can decide to do followings:

  1. If real progress is behind ideal work, it means project is behind schedule and group should increase their work.

  2. if real progress is ahead of ideal work, it means project is going good and group can relax a little bit.

Sprint

  • Sprint is the essential part of scrum, which is a set period of time during which specific work has to be completed. The duration of a sprint is determined by scrum master, and should be same for all sprints. It is traditionally 30 days.
  • Sprints consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
  • "Sprint Planning" is a meeting where Release Backlogs are prioritized and scheduled. The output of this meeting is called "Sprint Backlog", the total works that will be done in the Sprint.
  • "Daily Scrum" is a daily 15 minutes meeting for development team to synchronize activities and create a plan for the next 24 hours. Daily Scrums help detecting and solving a problem before it becomes a major issue.
  • When the sprint is completed, a "Sprint Retrospective Meeting" should be arranged in order to see the progress and discuss the improvements.

Team Members

  • Team Lead: This role, called “Scrum Master” in Scrum or team coach or project lead in other methods, is responsible for facilitating the team, obtaining resources for it, and protecting it from problems. This role encompasses the soft skills of project management but not the technical ones such as planning and scheduling, activities which are better left to the team as a whole (more on this later).
  • Team Member: This role, sometimes referred to as developer or programmer, is responsible for the creation and delivery of a system. This includes modeling, programming, testing, and release activities, as well as others.
  • Product Owner: The product owner, called on-site customer in XP and active stakeholder in AM, represents the stakeholders. This is the one person responsible on a team (or sub-team for large projects) who is responsible for the prioritized work item list (called a product backlog in Scrum), for making decisions in a timely manner, and for providing information in a timely manner.
  • Stakeholder: A stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, the "gold owner" who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project.
  • Technical Experts: Sometimes the team needs the help of technical experts, such as build masters to set up their build scripts or an agile DBA to help design and test their database. Technical experts are brought in on an as-needed, temporary basis, to help the team overcome a difficult problem and to transfer their skills to one or more developers on the team.
  • Domain Experts: As you can see in Figure 2 the product owner represents a wide range of stakeholders, not just end users, and in practice it isn't reasonable to expect them to be experts at every single nuance in your domain. As a result the product owner will sometimes bring in domain experts to work with the team, perhaps a tax expert to explain the details of a requirement or the sponsoring executive to explain the vision for the project.
  • Independent Tester: Effective agile teams often have an independent test team working in parallel that validates their work throughout the lifecycle. This is an optional role, typically adopted only on very complex projects (or at scale).

Organization structure of a small agile team.

References