Understanding Scrum

With Waterfall Model, it takes 9 months to 1 year even more to complete a software development, which includes

1. Requirement Gathering
2. Analysis And Planning
3. Design
4. Development
5. Testing
6. UAT
7. Deployment.

These are the typical phases of waterfall, Refer the image to get a pictorial representation of the model in high level.

The typical documents this model generates are like

1. Requirement Specification
2. Project Specification
3. Design Specification
4. System Specification
5. Test Cases
6. Tractability Matrix, etc

Using this model the return of investment started visible by end of all the phase(1 year or so).

• Preliminary Analysis
• System Analysis
• Requirement Definition
• WBS / Project Plan
• System Design
• Development
• Integration & Testing
• UAT
• Installation & Deployment
• Maintenance

• Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of changing.

• Requirements are very well known, clear and fixed.
• Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements
• Ample resources with required expertise are available freely

We already learn so far the considerations, limitations and disadvantages of Waterfall model on this dynamic market place. Now lets see how development with Agile Mindset overcome those challenges. I will not cover the history of Agile, how it is evolved. But will talk about little difference between Waterfall and Agile, In this article I will highlight primarily the Scrum framework.

The diagram demonstrate the difference between Agile and Waterfall with the three components Cost , Schedule, Scope

In waterfall we talk about the Scope is fixed, what varies is Cost and Schedule. That means we need to calculate how much time and cost it will take to deliver this scope.

Where In Agile the Scope is variable and cost and Schedule is fixed, where we can plan or calculate how much Scope we can deliver with this Cost and Schedule.

Lets develop a cake, and assume one complete cake is our complete product. with traditional way of development, we will able to complete the whole cake by one year. Assume each layer of the cake is one phases of development. refer the image below to get the explanation better.

To develop the full cake it may take a year (hypothetically), by the time the cake is developed, Market demand may changed to a different flavor of cake, The return of investment will delayed for a year, and that too with uncertainty and risks.  So the Industry has adopted an another way to develop and deliver to counter these uncertainty and risks. And Agile way of working is the mindset to overcome the risks and uncertainty. Scrum is one framework which follows the Values and principle of agile.

Lets see the same cake development with Scrum.

With in Scrum The product Owner, for this example The Bakery Owner have a detail vision what to develop, but to get the return of investment faster, he/she decided to create one slice of cake first. This is called vertical slicing. where we will create one vertical slice instead of the whole product. upon completion of each vertical slice can be put into market and ready to sell. Each vertical slice will take less time, will have less risks and uncertainty.

Refer the image below, to understand the concept better.

Now assume each slice development is a Sprint the Timebox or iteration of scrum, which we will explain in details later. each sprint have its own phase of requirement gathering or analysis, design, development, testing etc.

After completion of each sprint we will able to make some potential sell-able of ship-able product.

That is the essence of working with Scrum framework. Product Increment with Iterative and incremental way. when it comes to software development we need to follow some principles and values. and also we need to think about releases Goals, Sprint Goals etc.

The diagram below explain a scrum way of development to demonstrate product increment on iterative time boxes.

Our Primary focus of this article is to understand Scrum, will not talk about Agile much, there are some important Agile Values which Scrum also inherit along with Scrum Values.

The Agile Values are as below, which follows all framework under agile.

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

for details of Agile Values and principal refer to Agile Manifesto

We will distribute the Lifecycle in two parts one is Ongoing activity and another is Iterative activity.

Ongoing Activities

There are some on-going activities, means not depend upon sprints or Iteration. like Creation of product Backlog Item (mainly stories), Prioritizing the product backlog Item, Backlog grooming, Define the definition of ready and done. These activities are needed to be continue, better to be in cadence.

Iterative Activities 

These are are activities a scrum team execute with in a sprint and outcome of those activities consumed or utilized within the sprint. like Sprint start with Capacity Planning, Sprint Planning, continue Daily stand-up for every day, sprint end with Retrospective and Review. with in a sprint the Team has a Goal to deliver and a maintain a Scrum Board to have the visual representation of the progress, roadblocks etc.

The team commit to a set of product backlog items during sprint Planning based on their capacity. Maintain burndown chart to check the remaining amount of work for the sprint every day.

Product Backlog

Product Owner has a vision of product, Product owner understand the value of each and every functionality to be developed. He/She creates all those expected functionality as requirement in form of User Story and make a list of all those user story at one place in right order of execution. That list is Product Backlog, and the arranging those user story in right order is Prioritization

Click here understand more about User Story

Click here to learn more about Prioritization

The Items inside Product Backlog are usually User stories, however a Product Backlog can also have

• Technical Spikes,
• Bugs or Defects
• Epics or
• Features
• etc.

So each Item inside product Backlog is also called PBI (Product Backlog Item). and to summarize we can say Product backlog is list of prioritized work item.

To explain characteristic of a Good Product Backlog there is a popular Acronym called DEEP

Roman Pichler, author of “Agile Product Management with Scrum: Creating Products That Customers Love“ and I use the acronym DEEP to summarize key attributes of a good

• Detailed Appropriately. The Product Backlog Item Need to have enough details in appropriate way to understand what exactly the ask is and expected functionality in details, with all validations and logic.
• Estimated. The Product Backlog Items is not just only the requirement, its should also provide enough data to Plan for releases and milestones. its very important to have estimated backlog to plan effectivly
• Emergent. Creation of backlog item is not one time activity, Its a dynamic content log. It change over time. With time and knowledge the Product backlog Item can be added, removed, re prioritized, modified.
• Prioritized. The product backlog should be ordered with the most valuable items at the top and the least valuable at the bottom of the list. By always working on the most valuable item first, the team will able to maximize the value of the product increment.

Burndown Chart

Burndown chart is not a part of requirement, however its a important artifact to track the remaining hours of work for any specific sprint. Its also starts at beginning of a sprint and become history after that sprint closure. Each Sprint have its own burn down.

Sprint Burndown chart is a visual representation of remaining works for the scrum team of a specific sprint. Burn-down charts represents the real time total amount of work as pending for the sprint of any team, amount of work can be measured as remaining effort hours, or story points. Using the unit as “task hours” rather than “story points” is always better for burn-down chart. I personally suggest to use task hours to plot the burn-down chart.

To Understand more about burndown chart read about it in details from the link below, or watch this video .

More about Burndown Chart

Other Artifacts (DOR & DOD)

DOR or Definition of ready and DOD Definition of Done are the checklists defined by the scrum team before the first sprint, some time during Sprint 0.

This two check lists are useful to avoid any kind of conflicts and give a direction and standard to work on.

DOR : Helps the team to decide and measure for any particular PBIs is ready for the sprint. that means if the PBIs meets all the check point  of the DOR, the it can be taken for sprint for execution. Scrum Master and the team validates the PBI from the DOR checklist before committing for a sprint.

DOD : Similarly any PBIs that is currently under active sprint, should only be treated as done if its meet the definition of done. Product Owner who is responsible to accept the PBI completion, refer this Checklist to mark a story or any PBI as done.

There is noticed negative aspect of this DOR and DOD, Many teams misuse the presence of DOR and DOD and become very strict to Commitment and Acceptance, which ultimately decrease the Incremental flow. Please Inspect current situation of your development piece, and update the DOD and DOR if it is required. Also don’y change the DOR / DOD very frequently, then it will lose the main purpose.

These are the example of DOR and DOD to get a reference. Please define your own DOR/DOD as per the Need and nature of work.

Sample Definition of Ready

• Story must be written as a user story (i.e. “As a <kind of user> I want <feature> so that <benefit>”)
• Acceptance criteria must exist and be understood by team
• Story has been estimated by the team
• UX sketches exist, where appropriate, and are understood by team
• Performance criteria exist, where appropriate, and are understood by team
• The team understands how to demo the feature

Sample Definition of Done

1. X% of code coverage from Unit Test
2. Automated tests for the User Story are created and pass
3. Acceptance criteria is met
4. All regression testing of the product is moving
5. System-level Non-Functional requirements ( e.g. System-level performance) tested and passed
6. Software is running in the server to be defined by the team (optimally in pre-production)
7. Code review by peer
8. Technical documentation updated
9. User documentation updated
10. User Documentation is localised
11. Localisation for the story is done
12. Localisation testing is done
13. Marketing input is done
14. Legal documents are done
15. Beta Testing is done

From the image below try to understand at what workflow stage these DOR and DOD can be refereed

There are three distinct role in Scrum

1. Product Owner
   Holds the vision for the product
2. Scrum Master
   Helps the team best use Scrum to build the product
3. Development Team
   Builds the product

There is some instance where you may get a chance to another team called cross function team. We will learn high-level about these roles and responsibility. In details I will write in-depth article on each scrum Roles and Responsibility some time later.

Let’s See who is Product Owner and what is his primary role

Product Owner

To develop any products, we need Requirement || Execution || Delivery. The Product Owner is responsible for Gathering requirements from Business Owner or stake holders or some time from his/her own expectation. So from people prospective Product Owner is the single source of requirements. Product Owner who breaks the large requirement into small functionality in form of user stories. PO adds the user stories into a place call Product Backlog. This Product Backlog can be anything like Excel list of rows, each row represents an Indipendent small fully function requirement, or any ALM tools like Jira, CA-Agile Central (Rally), TFS, Version one etc.

Apart from creating user stories, PO is also responsible for

1. Prioritizing the list of user stories in Product Backlog.
2. Make the development team understand the requirement and expectation of each user story, in priority.
3. Participate on major scrum ceremonies

Product Owner has the authority to accept or reject the story completion, keeping DOD as rule book. He/she continuously work together with the team during each sprint, and provide feedbacks by accepting or rejecting of user stories when development team mark it as developed and tested.

Product Owner and only Product Owner has the authority to terminate any active sprint, if he/she realize the committed user stories will not add any value increment to the specific situation.

Product Owner become a bridge between the Scrum team and Business. PO helps the team to visualize the vision of the Business.

Product Owner also invite stake holders during sprint review to demonstrate the upcoming Product Increment, and also capture feedbacks from Business Sponsor or stake holders to make the product Backlog up-to date and emergent.

At many Instance Product Owner seems to be little occupied with other engagement, on those cases a Business analyst seems to have compensate the gap and shadow product owner for few responsibilities like Creating and Maturing User Stories, making team understand the requirement etc. The authority of prioritizing, Accepting, rejecting story completion, Terminating Sprint are still being with PO only.

It’s always suggested that the Product Owner should be from Business side to maximize the benefit of working together.

Scrum Master

The role of a scrum master is to protect the Agile process, maintain the discipline by ensuring the team follows the best practice of agile and maximize the value increment. Scrum Master is a Servant Leader is a facilitator , is a local coach to the team. Scrum Master Prompts and Supports Scrum. Scrum Master helps every one to understand Scrum theory, Practice, Rules and Value. and maximize the value outcome.

Scrum Master also know as process owner. Scrum Master Servers to all other Roles and cross function team as well.

The high level responsibilities of this role include:

• Establish the Scrum Framework
• Enableing Transparency, Inspection and Adaptability
• Resolving Impediments
• Establishing a environment of Agile Development
• Protecting the team from outside interruptions and distractions.
• Represent a holistic approach

Scrum Master Organize, facilitate and participate all agile ceremonies, does reporting wherever required, Maintain data for metrics and Trend analysis, Train people to understand scrum framework and its process and its value, Coach teams to get the benefit of scrum to maximize the value increment.

Scrum Master is not a Manager, Scrum Master don’t have authority to hire or fire. Scrum Master can not take a secession of Skill allocation, or task allocation, Scrum Master don’t participate in estimation, however he facilitate the estimation process.

Development Team

The development team is the group of technical team responsible for construction of the product by coding, designing, testing etc.

This group of people are having a combination of technical skills, and capable of converting the vision of product owners into use able functionality, which become contribute to the final product.

Remember the development team should skill set of people which in together can complete the construction of all committed user stories, from beginning to end (Analysis, Design, Development, Testing, Review) with in one sprint.

That means it should not have

1. Two or more teams for performing different set of skill set. having one team for design and another of development and another for testing, is wrong and bad team structure.

Its a good practice to have development team structure fixed, means the team membranes should be part of same team for as many sprint as possible. Changing the team structure very frequently is not good practice, which breaks the rhythm, and decrease productivity.

Development team takes participate at all Scrum ceremonies with defined responsibility, will cover details roles and responsibility at some other article.

Lean more and in details about Capacity Planning

Though Scrum is for continuous Development and Delivery, There are some metrics you can maintain to analyze the trend, inspect and adapt. I have explained each of these metrics under the video on right side.

1. Velocity Trends
2. Commitment Reliability
3. Capacity Utilization
4. Scope Change
5. Defect leakage
6. Backlog Health