Dictionary meaning of Agile is quick moving. Agile development methodology considers software as the most important entity and accepts user requirement changes. Agile advocates that we should accept changes and deliver the same in small releases. Agile accepts change as a norm and encourages constant feedback from the end user.
The Agile Manifesto
Below figure shows how Agile differs in principles from traditional methodologies.
• It’s 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 Owner’s 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, theSprint, 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 time-box, is when team decide upon what will be done in the Sprint. The second part, another four-hour 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
The Agile Manifesto
Below figure shows how Agile differs in principles from traditional methodologies.
• It’s 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 Owner’s 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, theSprint, 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 time-box, is when team decide upon what will be done in the Sprint. The second part, another four-hour 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.
During the entire sprint, team does the following major activities:
Scrum Master
• Daily scrum and SoS meeting
• Burn-down tracking
• Roadblock and dependency resolution
• Risk identification and mitigation plan
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 Activities
• Preparation of deployment schedule
• Design discussion & review
• Heuristic review as soon as UI is done
• Code review using code collaborator (code review tool)
• JUnit tests are written and executed Where ever applicable
• Deployment to QA environment
• Exploratory defect fixes
Testing Activities
• Preparation of acceptance criteria from BA
• Test case design creation (automation + manual (if needed)) and review
• Test case execution and automation script review
• Logging/verify 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 he or she has accomplished since the last meeting;
What he or she is going to do before the next meeting; and
What obstacles are in his or her way.
Daily Scrums improve communications, eliminate other meetings, identify and remove
impediments to development, highlight and promote quick decision-making, and improve everyone’s 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.
• 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 the entire sprint, team does the following major activities:
Scrum Master
• Daily scrum and SoS meeting
• Burn-down tracking
• Roadblock and dependency resolution
• Risk identification and mitigation plan
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 Activities
• Preparation of deployment schedule
• Design discussion & review
• Heuristic review as soon as UI is done
• Code review using code collaborator (code review tool)
• JUnit tests are written and executed Where ever applicable
• Deployment to QA environment
• Exploratory defect fixes
Testing Activities
• Preparation of acceptance criteria from BA
• Test case design creation (automation + manual (if needed)) and review
• Test case execution and automation script review
• Logging/verify 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 he or she has accomplished since the last meeting;
What he or she is going to do before the next meeting; and
What obstacles are in his or her way.
Daily Scrums improve communications, eliminate other meetings, identify and remove
impediments to development, highlight and promote quick decision-making, and improve everyone’s 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.
Comments
Post a Comment