7 Wastes in Software Development

1. Partially Done Work.
2. Extra Features.
3. Relearning.
4. Handoffs.
5. Delays.
6. Task Switching.
7. Defects.

Velocity in Scrum

velocity is the amount of work that a team can complete in a specified period of time.

The "amount of work" is the total number of story points if the team estimates by size, or the total number of "ideal hours spent on tasks. All acceptance criteria must be met in order for a story to be considered complete. The "specified period of time" is usually an iteration between one and four weeks long.

Velocity is simply work divided by time — story points per iteration or ideal hours per iteration.

Velocity is a measurement of how much the team gets done in an iteration ( called as Sprint in Scrum ). Velocity is what actually got done in the last iteration not what is planned.

In Scrum it is measure in Story points. Each feature in scrum is a story. A story has points. Points can be anything you come up with.

Highlight points for Velocity in scrum

1. Velocity = [Total number of story points moved to ‘done’ in a sprint].
2.  Product owner identifies a user-story as ‘done’/’not done’ during sprint review.A metric to measure of the Scrum team’s rate of progress.
3. Velocity is calculated at the end of every Sprint after Sprint review.
4. Velocity for a team improves over time based on closing the continuous improvement areas identified in Sprint retrospective.

User Story in Agile

User stories are used with Agile software development methodologies as the basis for defining the functions a business system must provide, and to facilitate requirements management. It captures the 'who', 'what' and 'why' of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard. User stories are written by or for the business user as that user's primary way to influence the functionality of the system being developed. User stories may also be written by developers to express non-functional requirements (security, performance, quality, etc.)

1. A user story represents a value adding requirement of the product.
2. Contract between development team and PO that discussion will take place before implementation.
3. This usually follows the following template:"As a <user type> I want to <do some action> so that <desired value added result>“.
4. INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable.
5. Implemented by a development team in one sprint.
6. User stories are Complemented by with conditions of satisfaction.

User stories Vs Use Cases

User stories

1. Provide a small-scale and easy-to-use presentation of information. Are generally formulated in the everyday language of the user and contain little detail, thus remaining open to interpretation. They should help the reader understand what the software should accomplish.
2. Must be accompanied by Acceptance Testing procedures (acceptance criteria) for clarification of behaviour where stories appear ambiguous

Use Cases

1. Describe a process and its steps in detail, and may be worded in terms of a formal model. A use case is intended to provide sufficient detail for it to be understood on its own. A use case has been described as “a generalized description of a set of interactions between the system and one or more actors, where an actor is either a user or another system”.
2. May be delivered in a stand-alone document.

Burn-up chart

• A chart displaying the current progress of the sprint and estimated time to burn down the complete product backlog.
• Displays the value earned through all Sprints.
• X-axis is the iterations since start of the project.
• Y-axis is the total ‘done’ effort.
• The green line is the total scope. The dashed line extrapolates the estimated total scope.
• The red line is the total scope ‘done’ for each iteration. The dashed line extrapolates the estimated time required to burn down entire scope based on Scrum team’s current velocity.

Sprint Burndown chart

By reviewing a sprint burn down report, you can track how much work remains in a sprint backlog, understand how quickly your team has completed tasks, and predict when your team will achieve the goal or goals of the sprint.

Burn down chart displays the remaining effort for a given period of time.

When they track product development using the Burn down chart, teams can use a sprint Burn down chart and a release Burn down chart. This article concentrates on the sprint Burn down chart as it is used on daily basis.

Sprint Burn down Chart

• A chart displaying the current progress of the sprint.
• Displays the remaining work in the current Sprint.
• Updated by the development team everyday.
• X-axis is the days remaining in the Sprint.
• Y-axis is the total estimated effort remaining to get the tasks identified for the Sprint to done.
• Green line is the ideal Burndown based on number of hours committed to in the Sprint.
• Red line is the daily estimations of remaining work updated by development team daily.

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.

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.