Twelve Principles of Agile Software

1.Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2.Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4.Business people and developers must work together daily throughout the project.
5.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The Sprint Planning Meeting – Warnings

1. The product owner does not attend the meeting.
2. The scrum master does not attend the meeting.
3. A major part of the team is missing from the meeting.
4. The product backlog is not prioritized or groomed.
5. Other stakeholders are part of this meeting and prioritizing activities.
6. The Sprint goal is vague.
7. Team doesn’t estimate even the top priority user-story into tasks.
8. The scrum master and/or product owner are deciding tasks taken into sprint backlog.
9. The scrum master and/or product owner are doing the estimates.
10. Meeting does not get over in the specified time-box.

Definition of Done (DoD) in Agile

 Done Done means the coding is done, it’s been tested, installers and deployment packages have been created, user manuals have been updated, architecture docs have been updated, etc.

1. A transparent exit criteria to decide whether an item in the product backlog is completely implemented.
2. An input for the development team to decide how much work it can commit to deliver in a sprint.
3. As the scrum team matures the exit-criteria become more strict.

Actually done means to finish below all mentioned activity :

Column One

User Story Clarity
User stories selected for the sprint are complete with respect to product theme, understood by the team, and have been validated by the detailed acceptance criteria.

Tasks Identified
Tasks for selected user stories have been identified and estimated by the team.

Build and package changes 
Build and package changes have been communicated to the build master. These changes have been implemented, tested and documented to ensure that they cover the features of the sprint.

Product owner approval
Each finished user story has been passed through UAT (User Acceptance Testing) and signed off as meeting requirements

Updating Product Backlog
All features not done during the sprint are added back to the product backlog. All incidents/defects not handled during the sprint are added to the product backlog.

Column Two

Environment ready

• Development environment is ready with all third-party tools configured.
• Staging environment is ready.
• Continuous integration framework is in place. The build engine is configured to schedule hourly, nightly, and release builds.
• Desired build automation is in place. Why "desired"? Because there is no end to build automation :)
• Test data for the selected features has been created

Design complete
Design analysis is complete as per the user story or theme. UML diagrams are either created or updated for the feature under development.

You might need to prototype various components to ensure that they work together.  Wireframes and prototype have been created and approved by the respective stakeholders.

Unit test cases written
Unit test cases have been written for the features to be developed.

Documentation Ready
Documentation (Just enough or whatever the team agrees to) to support the sprint demo is ready

Pre-Release builds 
Pre release builds (hourly/nightly) have been happening and nightly build reports have been published on regular basis.
The following could/should be part of pre-release builds:

1. Compile and execute unit test cases (mandatory)
2. Creation of cross reference of source code
3. Execution of automated code reviews for verification of coding rules
4. Code coverage reports are generated
5. Detection of duplicate source code
6. Dependency analysis and generation of design quality matrix (static analysis, cyclomatic complexity)
7. Auto deployment in staging environment
8. It comes down to build automation; there is no end to what can be achieved from automated hourly, nightly builds. The team along with the product owner needs to decide on how much build automation is required.

Column Three

Code Complete
Source code changes are done for all the features in the “to do” list.” Source code has been commented appropriately.

Unit testing is done
Unit test cases have been executed and are working successfully

Code Refactoring
Source code has been refactored to make it comprehensive, maintainable and, amenable to change.

A common mistake is to not keep refactoring in the definition of done. If not taken seriously, refactoring normally spills out to next sprint or, worse, is completely ignored.

Code checkin 

1. Source code is checked in the code library with appropriate comments added.
2. If project is using tools which help in maintaining traceability between user stories and the respective source code, proper checkin guidelines are followed.

Code merging and tagging
Finalized source code has been merged with the main branch and tagged appropriately (merging and tagging guidelines are to be used)

Column Four

Automated Code reviews
Automated code review has been completed using the supported tools/technologies. Violations have been shared with the team and the team has resolved all discrepancies to adhere to the coding standard. (Automated code reviews should be hooked up with CI builds.)

Peer reviews
Peer reviews are done. If pair programming is used, a separate peer review session might not be required.

Code coverage is achieved
Code coverage records for each package are available and whatever the team has decided as the minimum benchmark is achieved.

Project metrics are ready
Burndown chart has been updated regularly and is up to date.

Release Build

1. Build and packaging
2. A Build (successful) is done using continuous integration framework. Change log report has been generated from Code Library and Release notes have been created. Deliverables have been moved to release area.
3. Build deployment in staging environment
4. Build deliverables are deployed in staging environment. If it is easy, this step should be automated.

Column Five

Functional testing done
Automated testing
All types of automated test cases have been executed and a test report has been generated. All incidents/defects are reported.
Manual testing
Quality assurance team has reviewed the reports generated from automation testing and conducted necessary manual test cases to ensure that tests are passing. All incidents/defects are reported.
Build issues
If any integration or build issues are found, the necessary steps are repeated and respective “Done” points are adhered to.
Regression testing done
Regression testing is done to ensure that defects have not been introduced in the unchanged area of the software.
Performance testing done
A common mistake is to not keep performance testing in the definition of done. This is an important aspect. Most performance issues are design issues and are hard to fix at a later stage.
Acceptance testing done
Each finished user story has been passed through UAT (User Acceptance Testing) and signed off as meeting requirements (see also Product Owner Approval).
Closure
All finished user stories/tasks are marked complete/resolved. Remaining hours for task set to zero before closing the task.

Sprint Retrospective Meeting

1. Meeting for scrum team to retrospective on how the Sprint went with respect people, process and tools.
2. Team identifies what went well and what can be improved.
3. Team identifies a plan to implement identified improvements.
4. Other stakeholders are not allowed.
5. An opportunity for the team to make continuous improvements.
6. Maximum time box of 3 hours for a 4 week Sprint

The Sprint Retrospective Meeting - Warnings

1. The retrospective meeting is not conducted.
2. Identified improvements are not followed up with actions.
3. The scrum master or/and development team does not attend.
4. Other stakeholders are not allowed.
5. Maximum time box of 3 hours for a 4 week Sprint.

What is Sprint Retrospective?
Each Sprint in Scrum has to a meeting – Sprint Retrospective at the end. It is very essential that the Scrum Master never allows the team to skip these meetings. These meetings uplift Inspect and Adapt principles of Scrum and help the product to be better and better after each Sprint.

Team along with Scrum Master asks 2 questions:

• What went well in last sprint?
• What could be improved in next sprints?

  Rules for Sprint Retrospective ?

1. Ensure that everyone can speak freely.
2. Sprint retrospective meeting is not the place for advocating ones personal agenda.
3. Do not play the blame game.
4. Do not allow vague statements.
5. Transform identified improvements to concrete action points.

Key elements of the Sprint Retrospective are:

• Process improvements are made at end of every Sprint - ensures that the project team is always improving the way it works.
• The Retrospective is a collaborative process between all members of the Team, the Product Owner, and the Scrum Master.
• All team members identify what went well and what can be improved
• Scrum Master prioritises actions and lessons learnt based on Team direction
• Team devises solution to most vexing problems - helps to build the team ownership and self management.
• Helps the team formation and bonding as any areas of conflict can be identified and dealt with.

The Sprint Review Meeting

1. Meeting held to demo the increment delivered by development team.
2. Dev team demos all items it has “done” and clarifies queries about it.
3. Everyone is invited. PO and all stakeholders see the demo.
4. PO confirms on what is “done” and what is “not done” in the increment.
5. PO discusses the product backlog at that point. Everyone discuss on what has been achieved and what to do next. Product backlog is revised as needed.
6. Maximum time box of 4 hours for a 4 week Sprint

The Sprint Review Meeting - Warnings

1. Product Owner does not attend the sprint review meeting.
2. Dev team demos what it has done in a simulated environment rather than actual production environment.
3. Members from the development team skip the demo.
4. Demo is shown on code from development environment rather than production environment.

The Daily Scrum Meeting - Warnings

1. The Scrum Master does not ensure that the daily Scrum is conducted.
2. The development team does not show interest in attending the meeting.
3. The development team members speak to the scrum master / product owner / another manager rather than addressing the team.
4. Team members tend to solve the problems raised in the meeting then and there.
5. Meeting extends beyond 15 minutes.
6. Managers tend to take over the meeting and direct discussions.

What Is Agile?

First, what does agile really mean?  It’s not considered a methodology, a process, or even a set of procedures.  It’s more of a conceptual development framework which allows our team to iteratively prioritize & plan the work, perform the work, and review the work.  As opposed to the classic waterfall approach, agile acknowledges that we don’t have all the answers at the start of a project. 

1. Agile value individuals and interactions over processes and tools.
2. Agile value working software [or any product] over comprehensive documentation.
3. Agile value customer collaboration over contract negotiation.
4. Agile value responding to change over following a plan.

The Daily Scrum Meeting

1. Daily synchronization and planning meeting.
2. Time box is 15 minutes maximum.
3. Held at same place and time everyday.
4. Open to all but only development team can talk in the meeting.
5. Others can only observe.
6. Not a problem solving meeting.

Each team member answers these 3 questions:

1. What was accomplished since last meeting?
2. What will be done before the next meeting?
3. What impediments are blocking this?

Daily Scrum Meeting Rules

1. Hold the Daily Scrum in the same place at the same time every work day. The best time for the meeting is first thing in the day so that Team members think about what they did the day before and what they plan to do today.
2. All Team members are required to attend. If for some reason a Team member can't attend in person, the absent member must either attend by telephone or by having another Team member report on their status.
3. Team members must be prompt. The ScrumMaster starts the meeting at the appointed time, regardless of who is present. Any members who are late pay a fine that is donated to a worthy charity!
4. The ScrumMaster begins the meeting by starting with the person immediately to his or her left and proceeding counter clockwise around the room until everyone has spoken.
5. Each Team member should respond to the following questions:
6. What have you done since the last Daily Scrum regarding this project?
7. What will you do between now and the next Daily Scrum meeting regarding this project?
8. What impedes you from performing your work as effectively as possible?
9. Team members should not digress beyond answering these three questions into issues, designs, discussions of problems, or gossip. The ScrumMaster is responsible for moving the meeting along briskly from person to person.
10. Team members should address the Team. This is not a "Reporting to the ScrumMaster" meeting.
11. During the meeting only one person talks at a time. Everyone else listens without any side conversations
12. Chickens (non Team members) are welcome to attend the Daily Scrum Meetings but they are not allowed to talk, make observations, make faces or otherwise make their presence in the meeting obtrusive.
13. Chickens stand on the periphery of the Team so as not to interfere with the meeting.
14. If too many chickens attend the meeting, the ScrumMaster can limit attendance so that the meeting can remain orderly and focused.
15. Pigs or chickens who cannot or will not conform to the above rules can be excluded from the meeting (chickens) or removed from the Team (pigs).

The Sprint Planning Meeting

Who, What, When, Where, Why
The Sprint Planning Meeting is attended by the product owner, Scrum Master, and the entire Scrum Team. Outside stakeholders may attend by invitation of the team, although this is rare in most companies.

Two defined artifacts that result from a sprint planning meeting:

A sprint goal

A sprint backlog

A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner. The following are typical sprint goals on an eCommerce application:

There are two parts in Sprint Planning Meeting

Part 1 – Prioritization 

What needs to be done by the end of this upcoming Sprint?

1. PO presents the ordered backlog items to the team.
2. Team discusses and understands the work for this Sprint.
3. Team forecasts and commits on the items that can be done.
4. Team creates the Sprint Goal for this Sprint.

Part 2 – Planning How will the chosen work get to done?

The output of the second planning meeting will be the Sprint Backlog.

1. Team arrives at the plan to get the items to done in a Sprint Backlog.
2. Team arrives at a design and work needed to achieve the Sprint goal.

Scrum Sprint

Events in the Scrum Framework
Sprint = [ Sprint planning meeting + Daily Scrum +Development work + Sprint review + Sprint retrospective ]
Time-box of less than a month when team gets to “Done” a potentially shippable product increment.•Each Sprint contains:

1. A goal.
2. A design and plan to reach the goal.
3. The work done to achieve the goal.
4. The product increment.

The Sprint Cycle

Each sprint begins with a planning meeting. During the meeting, the product owner (the person requesting the work) and the development team agree upon exactly what work will be accomplished during the sprint. The development team has the final say when it comes to determining how much work can realistically be accomplished during the sprint, and the product owner has the final say on what criteria needs to be met for the work to be approved and accepted.

The duration of a sprint is determined by the scrum master, the team's facilitator. Once the team reaches a consensus for how many days a sprint should last, all future sprints should be the same. Traditionally, a sprint lasts 30 days.

After a sprint begins, the product owner must step back and let the team do their work. During the sprint, the team holds daily stand up meeting to discuss progress and brainstorm solutions to challenges. The project owner may attend these meetings as an observer but is not allowed to participate unless it is to answer questions. (See pigs and chickens). The project owner may not make requests for changes during a sprint and only the scrum master has the power to interrupt or stop the sprint.

At the end of the sprint, the team presents its completed work to the project owner and the project owner uses the criteria established at the sprint planning meeting to either accept or reject the work.