CSC/ECE 517 Fall 2012/ch2a 2w6 ar

Introduction

Scrum is an agile development framework that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.

Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.

Scrum framework

Following are the major activities constituting Scrum framework:

a) A product owner creates a prioritized list of user stories called a product backlog.
b) During the phase of sprint planning, the team of developers pulls a small chunk of user stories, and decides how to implement those pieces.
c) The team has a certain amount of time, a sprint, to complete its work - usually two to four weeks - but meets each day to assess its progress which is also termed as daily scrum.
d) Along the way, the ScrumMaster keeps the team focused on its goal.
e) The sprint ends with a sprint review and retrospective.
f) As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

Advantage of Scrum over traditional classical models

It follows a flexible approach not just in the software requirements phase, but also to the operational processes, thus the Scrum Framework optimizes usage of time and cost. It results in better product quality as with after each sprint a fully tested module is formed. Also, it increases productivity and customer satisfaction.

In the traditional waterfall model there are fixed phases which involves requirements analysis, design, development, test and maintenance. The drawback of it is that if there is a delay of any of the phases then there is a overall delay. Also, if any changes are to be made during any of the phases it is very expensive, time taking and extremely difficult for the team to go back.

Attempts are made to cover all possible requirements at the initial phases so that a product is developed which largely satisfies the customer’s needs. However, usually by the time the product is developed the requirements of the customers change. As the time span in which the product will be developed and delivered is determined at the initial phase usually it tends to exceed its deadline. After all the analysis it is found that for developing and implementing small projects waterfall model is preferred while for larger complex projects agile development practices are generally preferred.

Fundamental Roles in Scrum practice

Following are the major roles played by team member of a software development team following Scrum practices:

Product Owner

The major role of the product owner is to convey the customer’s requirements to the team and communicate the vision of the project. He/she plays a very important role and thus possess major responsibility in the project development.He/ she needs to handle the authority and the work load in a very efficient way. Should be aware about all the intricacies of the project as has to handle the queries of customers and the team.

ScrumMaster

The ScrumMaster acts as a liaison between the Product Owner and the team. The ScrumMaster does not manage the team. Instead, he or she works to remove any problems that are obstructing the team from achieving its sprint goals. In other words he/she helps the team in there experimentation and creative while constantly focusing that it meets the needs of the product owner.

Team Member

In the Scrum methodology, the team is responsible for completing work. Ideally, teams consist of seven cross-functional members, plus or minus two individuals. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. This grants teams a great deal of autonomy, but, similar to the Product Owner’s situation, that freedom is accompanied by a responsibility to meet the goals of the sprint.

Sprint Activities

There are several activities which form the basis of scrum implementation for team management. Following are the various terminology used and how they are placed in process is defined in next section.

Daily Standup meeting

It is a daily team meeting in which every team member provides the status of his current task. It is a quick meeting (generally timeboxed < 15 mins/team) and helpful in getting idea about the current sprint status. Every team member provides status in terms of answer to following questions:

  1. What did I done yesterday?
  2. What will I do today?
  3. Any blocking issue?

Status update generally takes around 2-3 mins per person as only high level information is stated like “yesterday I checked in code related to courses module. Today I will start working on designing GPA calculation module. No blocking issue as of now.” If a team member is facing any blocking issue then it is the responsibility of scrum master to get that resolved. These meetings are called “stand-up” because attendees stand at the meeting, so that discomfort of standing for long periods help to keep the meetings short. Generally, attendees include scrum-master, developers, QA team and product owner is optional.

Scrum of Scrums

Scrum principles suggests that average team size should be in between 5-8. In case a project has large team size then they are divided into several small teams. Each team does its daily standup meeting separately. In such scenario, scrum master of each team meet up with product owner after the daily scrum and each scrum master discusses

  1. What his team done yesterday (only major description)?
  2. What will his team be doing today?
  3. Any particular blocking issue his team is facing?

This is in particular behavior of daily scrum of scrum meeting. If this meeting is not held daily then scrum masters reports based on what his team has done since last meeting and what they will be doing since next meetup?

Sprint Planning Meeting

During this meeting, the product owner describes the highest priority features to the team. It is attended by the product owner, Scrum Master and the Scrum team. Team asks question about the new feature so that they can perform detailed task breakdown of a high-level user story while task estimation. As developers have good understanding of the code base they may put question related to implementation issues.

This meeting is generally held on first day of sprint cycle and it helps in clarifying the Sprint goal (i.e. short term deliverables expected in this sprint) and adding user stories and tasks in Sprint backlog.

Also task estimation can also be clubbed with this meeting. In which every team member announces his/her availability for the upcoming sprint (i.e. number of hours available). After that team member discusses the user stories and tries to identify the independent task required in order to implement a particular user story. Task are made such that they are independent and each task should not be greater than 5hrs. time. Task are broken down like this so that every team member has the freedom to work on any open task present in current sprint. A team member is allowed to assign only one task at a time. Thus giving a flat hierarchy in team which in turns favors the team building.

Sprint Retrospective

During this meeting scrum team and scrum master review the last sprint. This meeting is held on the last day of Sprint and every team member answers following three questions based on his experience for the past sprint:

  1. What went good? ( like “My story went pretty smooth and completed on time.”)
  2. What went bad? ( like “There were major issues in implementation specifications
        because of which module implementation took more than the estimated time.”
  3. Action Items (like “I feel that this particular module is very tricky and 
        we can add a hygiene user story to refactor the code related 
        to this module in product backlog.”)

This meeting is facilitated by the scrum master and it plays significant role in process improvement which in turn allowing agility in processes too.

Sprint

In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a sprint. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.

Scrum methodology proposes that every team must deliver a shippable product at the end of a sprint, no matter how basic that product it. One of the major objective of Agile methodology is ‘Deliver working solution’ which infact is achieved by the concept of sprint. Prior to start of a particular sprint, a team commits a particular feature/module for that sprint i.e. team need to deliver that particular feature at the end of sprint (after 2 or 3 weeks- depending on sprint length).

As development of a feature involves various activities like task breakdown, design discussion, specs implementation, bench test plan creation, code/ functional review, testing time or any particular blocking issue; a team plans such that scope of module might be reduced but whatever committed should be delivered at the end and that too working perfectly i.e. without bugs.

At the end of a sprint, deliverables are tested based on two parameters:

  1. Did you build the thing right? i.e. proper coding guidelines are followed
        by the development team, code is peer-reviewed and testing is done 
        (both manual and unit testing)
  2. Did you build the right thing? i.e. deliverables are compliant to the specification 
        proposed by the customer.

If answer to both of the above questions are true only then a sprint is considered as a successful sprint. Due to time constraints, the team or scrum-master would only pick the tasks or user stories which are on release’s most essential features, encouraging developers to focus on short-term goals. As a product release requires many sprints for satisfactory completion, each iteration of work builds on the previous because of which Scrum is described as “iterative” and “incremental”.

Scrum Implementation(Real World Example)

Prior to sprint start

Ammy is assigned as the Scrum Product Owner of a new software development project. Her first tasks is to start requirement engineering. She writes down the most important use-cases and discusses them with the architects, customer representatives and other stakeholders. She gathers all the use cases and requirements and writes them into the Scrum Product Backlog and consults the senior software developers to assign priorities to each of them. As a result of this session all the items in the Scrum Product Backlog have an initial rough estimation and a prioritization. Now she starts to break-down the high-level requirements into smaller-grained user stories. With this list she then calls for the first Sprint Planning meeting.

Sprint 1 - Day 0

During the Sprint Planning meeting Ammy presents the Scrum Product Backlog items from the highest priority to the lowest. The team clarifies open questions . After this discussion they commit to complete the stories 1,2,3,6,7 and 8 until the end of this sprint. The items 4 and 5 cannot be realized in this sprint, as some technical requirements have not been met yet.

After the Sprint Planning meeting the Scrum Master of the team – to discuss how all the committed items are to be implemented. Then everyone from the team selects are a task.

Sprint 1 - Day 1

In the evening the whole team gets together for their Daily Scrum Meeting. Everyone gives a short statement what has been achieved so far, updates the estimation of remaining hours on the cards of the Sprint Task board, tells what he or she is planning to do next and tells if there are any impediments that hinders him to continue his work. After discussing for 15 minutes everyone goes back to work.

Sprint 1 - Day 2

In the evening again the whole team gets together for their Daily Scrum meeting. One of the Scrum team members is unsure about the specification of one of the user stories. He calls Ammy –Scrum Product Owner- and discusses the problem with her. After the team member finds out what to do, then he can continue with his implementation.

Sprint 1 - Day 28

This is the final day of the first Sprint and Scrum Master invites the team for the Sprint Review Meeting. The master reviews and checks the output software to check whether the software meets the requirements. At the end of the Review he concludes and classifies which user stories are completed, which are left incomplete and which need refactoring. Then the team gets together for the Sprint Retrospective Meeting and discusses what went well during the sprint and what improvements need to be made.

References

[Wikipedia Scrum Development]
[scrum.org/Resources/What-is-Scrum]
[scrummethodology.com/scrum-sprint/]
[agilearchitect.org/agile/principles.htm]
[en.wikipedia.org/wiki/Stand-up_meeting]
[mountaingoatsoftware.com/scrum/sprint-planning-meeting]
[scrummethodology.org/]
[pentalog.com/approach/agile-scrum-methodology.htm]
[axosoft.com/ontime/videos/scrum]
[versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/]
[http://mazzive.com/blog/?p=12]