Abstract
Agile is a software development methodology that is becoming more popular every day. It defines the mind set of many software development teams working across the globe. This article will walk you through the entire Agile-scrum process and how, as a developer, you can contribute in an Agile way and deliver value. BTW, Agile means ability to move quickly.
Agenda
- Life Cycle of a Developer
- Barriers to value delivery
- Agile Adoption
- Plan Driven Vs. Value Driven
- Agile Manifesto
- Scrum End-to-End Process
- Agile Estimation
- Daily Standup
- Agile-Scrum Tools
Life Cycle of a Developer
The 1st interaction a developer has is with a BA. They are responsible for documenting, tracking and describing the user requirements. But there are often gaps in understanding the requiremetns and that can cause issues in various ways.
The following image shows what the user wanted and what happened when it was implemented.
![]()
Stop the blame game
In many team settings, a developer is considered to be responsible for everything, right from understanding the requirements to code to the support of testing, help in deployment and then resolve production issues. Well, I always believed that the entire software development is a team effort. But in the end, in most cases developers bear most of the blame.
![]()
Agile has a fix for this mindset and enables the entire team to share responsibility, succeed together and fail together.
Team Barriers = Value Delivery Impediments
All .NET development teams want to deliver value but realisticallly what are barriers that stops a team to deliver value.
![]()
Every team has a dependency within and upon people outside, the communication gap and lack of understanding of the common goal is the root cause of Value Delivery Impediments.
Impact of Team Barriers
Well, most of the issues any software teams runs into has the following outcomes:
![]()
Increased Cycle Times: This means that you must work longer to get the work completed.
Increased costs: More time means more money.
Dissatisfied users and Stakeholders: The end-user missed the milestone of a feature being available and so it raises concerns for stakeholders as well.
Lost value opportunities: You will potentially not have more work from the same client.
Agile Adoption
![]()
Agile-Scrum is the most widely accepted methodology of Agile development. The term scrum is taken from the sport rugby in which the entire team works to get possession of the ball.
Plan Driven Vs Value Driven
![]()
![]()
Plan Driven (waterfall approach) is an old school that defines the software development life cycle. Many teams are still doing that though but in the waterfall plan takes precedence over value.
Value Driven (Agile approach) is a new way of building software; it gels teams, stakeholders and users very well and helps them team receive early feedback and fail quickly.
Manifesto for Agile Development
17+ people gathered in a ski resort and they came up with the Agile manifesto.
![]()
Understanding Types of Backlogs
In Agile-scrum there are the following two types of backlogs:
- Product backlog
- Sprint backlog
A Product backlog is a larger list of work items (in the Agile world it is known as User Stories), it is like a “Functional Specification Document” or System Requirements Specification Document or “Business Requirement Document” or whatever your organization likes to call it.
So whatever user requirements we have, they are all stored in a Product Backlog, backlog.
Sprint Backlog: A Sprint is defined as the time that teams work to deliver certain items from a product backlog. But before teams start working on those items (User Stories), they need to be properly defined.
Scrum: End -to-End Process
![]()
Agile Scrum Ceremonies
A Team works on a sprint for anywhere between 1-4 weeks. An ideal sprint duration is 2 weeks. So from a Product backlog some User Stories are moved to the Sprint Backlog and then the team works on those for 2 weeks. During those two weeks the following ceremonies are done.
Sprint Planning: this is 1st thing that takes place before any work can begin. In this meeting the team looks at the User Stories that the Product Owner thinks the team should work upon in the next sprint. the Team looks in detail at the given requirements, brainstorms, defines/reviews the acceptance criteria or the work, estimates and assigns the work to team member(s).
Daily Stand-Up: this is the status meeting among team(s) members; in this meeting each team member gives a status on the following three criterias:
- What I did yesterday.
- What I will do today.
- Am I blocked?
Sprint Review: this takes place after each User Story is completed, so the Product owner can accept the work.
Sprint Demo: this provides an opportunity to the entire team and the larger group of users to see all the work the team has completed and to see end-to-end functionality.
Sprint Retrospective: this gives an opportunity to the development team to discuss the following three things:
- What went well?
- What went wrong?
- What we want to improvise?
Agile Estimation
Agile offers the following two types of estimations:
- Story Points. They are the most commonly used Agile estimation technique.
![]()
- T-Shirt Sizing, some teams estimate User Stories in T-Shirt sizing.
![]()
Scrum Status Board
Agile enforces daily status reporting and therefore many teams use various ways to track and show the progress on each user story. I found that a detailed board like the following provides more visibility and tracks each task/activity related to a Sprint Item.
![]()
Agile Tools
There are many tools available for Agile-scrum teams, but I have found TFS and rally widely used in the industry. Both work on similar Agile-scrum concepts and are very user-friendly.
The following are the screenshots of TFS.
Sprint View in TFS
![]()
Workflow for Task Status
![]()
Drag and Drop support for ease.
![]()
Conclusion
Though Agile seems very easy to understand and implement, it's very challenging to apply it correctly and many organizations are not in agreement with what Agile brings and its way of delivering things. Startups are usually known to follow Agile rather well-established companies at the organization level. In other words, in a company a team might be doing Agile but various other teams or company's mindset might still be waterfall based. But Agile is an amazing methodology to deliver more value, regardless of whether you are working in an Agile team or not it's worth knowing about the Agile-scrum process.