User:Rkandha

From Expertiza_Wiki
Jump to navigation Jump to search

Product development, using Scrum, occurs in small pieces, with each piece building upon previously created pieces. Building products one small piece at a time encourages creativity and enables teams to respond to feedback and change, to build exactly and only what is needed. More specifically, Scrum is a simple framework for effective team collaboration on complex projects. Scrum provides a small set of rules that create just enough structure for teams to be able to focus their innovation on solving what might otherwise be an insurmountable challenge.

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 updates 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

 What his team done yesterday (only major description)?
 What will his team be doing today?
 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 in 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: What went good? ( like “My story went pretty smooth and completed on time.”) What went bad? ( like “There were major issues in implementation specifications because of which module implementation took more than the estimated time.” 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”.