AGILE

What is a change? Any activity (new story, defects, scope change in the existing story etc) that is impacting teams goal or commitment should be treated as a change for the team. In agile, once team enters into the sprint after that whatever changes coming into the sprint backlog should be treated as a new requirement. Agile Change Management Agile development welcome changes as far as they add value to the development. Agile software development teams embrace change, accepting the idea that requirements will evolve throughout a project. Product owner is the responsible for ROI and is the owner of the backlog. It is POs responsibility to assign work to the team. Team has the visibility of just one milestone. So it is absolutely fine if PO changes the requirement priority before the sprint starts. But discourage the requirement changes during the sprint. One of the 12 agile principles says Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. But Scrum suggests that we should freeze the requirements after the planning session as soon as team gives its commitment for the current sprint. After that any change coming should be treated as a new requirement and should follow the change management process. In Agile, requirements are discovered and evolved during the development. Change control comprises the procedures used to ensure that changes are introduced in a controlled and coordinated manner. Every change has a cost attached to it. Should we accept all the changes coming from product owner? I dont think so. So when cost is attached then as per the triple constraint other parameter schedule and scope has also some impact. So this is quite important that we give it the adequate attention all the time. The Agile Manifesto Below figure shows how Agile differs in principles from traditional methodologies.

Its not necessary to have hi-fi tools and process but a good team interaction can solve lot of problems. Working software is more important than documentation.

 Management should not pay attention to only customer contract rather interact with customer and analyze the requirements. In traditional methodologies we pledge to stick our plans but agile says If the customer wants to change, analyze and change your plan accordingly. Scrum teams are designed to optimize flexibility and productivity; to this end, they are self organizing, they are cross-functional, and they work in iterations. Each Scrum Team has three roles: 1) the ScrumMaster, who is responsible for ensuring the process is understood and followed; 2) the Product Owner, who is responsible for maximizing the value of the work that the Scrum Team does; and 3) the Team, which does the work. The Team consists of developers, application architect and QA with all the skills to turn the Product Owners requirements into a potentially releasable piece of the product by the end of the Sprint. Scrum employs time boxes to create regularity. Elements of Scrum that are time boxed include the Release Planning Meeting, the Sprint Planning Meeting, the Sprint, the Daily Scrum, the Sprint Review, and the Sprint Retrospective. The heart of Scrum is a Sprint, which is an iteration of 4 weeks most of the times. All Sprints deliver an increment of the final product that is potentially releasable or working software. One Sprint starts immediately after the other. Planning The Sprint Planning meeting is when the iteration is planned. It is time-boxed to around eight hours for a 4 weeks Sprint cycle. The first part i.e. sprint pre-planning meeting, a four hour timebox, is when team decide upon what will be done in the Sprint. The second part, another fourhour time box, is when the team figures out how it is going to build this functionality into a product increment during the coming Sprint. Sprint Preplanning Meeting OR Planning 1 Meeting There are two parts to the Sprint Planning Meeting: the What? part and the How? part. In the first part, the Scrum Team addresses the question of What? Here, the Product Owner presents the top priority Product Backlog to the team with the help of the some tool like Rally. The purpose of sprint preplanning meeting is to establish a plan and goals that the scrum teams will develop in the coming sprint. This meeting usually happens around 2 weeks ahead of the sprint planning/kick off day. Scrum Master organizes this meeting with the team, application architect and product owner. Outcome of this meeting is the draft sprint backlog along with the estimated user stories. Every team member discusses the sprint backlog user stories in details to have a good understanding of the requirement so that they can further analyze and estimate the requirements in detail. Major activities in this phase are: Sprint Backlog prioritization User stories walk-through by product owners Discuss and confirm all pre-requisite e.g. data model, UI mockup etc. Wireframe reviewed with UX team Point sizing of user stories The input to this meeting is the Product Backlog from the Rally (Project Management and requirement management tool), the latest increment of product, the capacity of the Team, and the previous experience and past performance of the Team. The amount of backlog the team selects is solely up to the Team. Only the Team can assess what it can accomplish over the upcoming Sprint. Having selected the Product Backlog, a Sprint Goal is crafted. Sprint Planning Meeting OR Planning 2 Meeting

In the second part of the Sprint Planning Meeting, the team addresses the question of How? During the second four hours of the Sprint Planning Meeting, the Team figures out how they will turn the selected Product Backlog i.e. sprint backlog during Sprint Planning Meeting (What) into a working software. The team does the following major activities during the planning meeting:

Kick-off meeting where Meta scrum master explains the rules or the updates for the upcoming sprint Capacity planning scrum master comes up with the available capacity. User stories query resolution with product owners, core team, modeling team, UI core teams etc. User story walk-through by Product owners for newly added user stories Vertical slicing of user stories (if needed) Determine Sprint defect backlog target Point sizing of newly added user stories and defects Refine Point sizing of user stories due to added complexities/unknowns to data model/wireframe Inter team dependencies should be identified and communicated Task planning, estimation and allocation Agree to sprint commitment The Product Owner is present during the second part of the Sprint Planning Meeting to clarify the Product Backlog. The sprint commitment is solely dependent on the available sprint capacity. Output of this meeting is the committed sprint backlog by the team.

Sprint A Sprint is an iteration. Sprints are time-boxed. During the Sprint, the ScrumMaster ensures that no changes are made that would affect the Sprint Goal. Both Team composition and quality goals remain constant throughout the Sprint. Sprints contain and consist of the Sprint Planning meeting, the development work, the Sprint Review, and the Sprint Retrospective. Sprints occur one after another, with no time in between Sprints.

Agile Based Development Model During Scrum the entire Daily Roadblock Risk sprint, team does and the following SoS dependency mitigation major activities: Master meeting tracking resolution plan

scrum Burn-down and identification

and

Team Daily scrum meeting Ongoing/as needed query resolution / discussion with PO, Data modeler and UX teams Collaboration meeting with onshore team (technical discussions) Internal user stories demo before PO Acceptance Preparation of acceptance schedule Product owner acceptance demo Development Preparation of deployment Design discussion & Heuristic review as soon as UI Code review using code collaborator (code JUnit tests are written and executed Where Deployment to QA Exploratory defect Testing Preparation Test case design Test case Logging/verify Activities schedule review is done review tool) ever applicable environment fixes

Activities of acceptance criteria from BA creation (automation + manual (if needed)) and review execution and automation script review the functional defects into the Rally

Sometimes, due to the ad-hoc activities like customer demo etc, team need to pick the new requirements/defects in the middle of the sprint. During these situations, scrum master works very closely with the team to identify the impact on the sprint commitment and communicates the same to the StoneRiver. Daily Scrum Each Team meets daily for a 15-minute status meeting called the Daily Scrum. The Daily Scrum is at the same time and same place throughout the Sprints. During the meeting, each Team member explains: What What What he he or she or she is obstacles has going are accomplished since the to do before the next in his or last meeting; meeting; and her way.

Daily Scrums improve communications, eliminate other meetings, identify and remove impediments to development, highlight and promote quick decision-making, and improve everyones level of project knowledge. The ScrumMaster ensures that the Team has the meeting. The Team is responsible for conducting the Daily Scrum. The ScrumMaster teaches the Team to keep the Daily Scrum short by enforcing the rules and making sure that people speak briefly. Daily SoS Scrum masters meet daily for 15 minutes status meeting called SoS. Scrum masters give their team status to the meta-scrum master. Sprint Review At the last day of the Sprint, a Sprint Review meeting is held. During the Sprint Review, the Scrum Team and stakeholders (PO, Customers, and Management etc) collaborate about what was just done. Each team gives a demo to the product owner based on the functionality just developed by the team. Before the review meeting, scrum master sends the list of the user stories to the meta-scrum master before the demo. Sprint Retrospective After the Sprint Review and usually prior to the next Sprint Planning meeting, the Scrum Team has a Sprint Retrospective meeting. During this meeting, the ScrumMaster encourages the Scrum Team to revise, within the Scrum process framework and practices, their development process to make it more effective and enjoyable for the next Sprint.

The purpose of the Retrospective is to inspect how the last Sprint went in regards to commitment, issues, people, relationships, processes and tools. The inspection should identify and prioritize the major items that went well and those items that-if done differently-could make things even better. By the end of the Sprint Retrospective, the Scrum Team should have identified actionable improvement measures that it implements in the next Sprint. These changes become the adaptation to the empirical inspection. These action items along with the minutes of meeting should be documented and circulated to the entire team by the scrum master.