Hello friends, Its end of May 2018. after a long gap I am writing once again, I was pretty much occupied for last few weeks with multiple areas.

This article is about one of the most important and commonly used framework of agile. As we earlier have covered many other articles on Scrum ceremonies, Roles artifacts etc. Here we will be connecting all those details learning in a framework called Scrum. We will understand here the agile development life cycle using scrum framework. Before I start let’s quickly talk about Why Scrum or even why agile , and then will jump into one of its framework called Scrum

Why Agile ? 

Before you jump into Scrum, lets just recall the traditional way of software development and the dis-advantages with that, and how Agile Mindset resolve those gaps and adding values.

Lets quickly talk about what is waterfall

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).

With Waterfall Model
Common Action Item
  • Preliminary Analysis
  • System Analysis
  • Requirement Definition
  • WBS / Project Plan
  • System Design
  • Development
  • Integration & Testing
  • UAT
  • Installation & Deployment
  • Maintenance
Disadvantages
  • 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.
Considerations
  • 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
Transitioning to Agile (Mainly Scrum)
Estimation-Time-cost-scope Traditional Vs Agile Estimation for User Story

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

What is Scrum 

Scrum is a framework for delivering and sustaining complex products, which collaboratively and a collectively resolve complex solution. Which delivers product on incremental way to generate faster return of investment. Scrum is not a Process or Methodology. Its Simple. Scrum implements the imperial model by Transparency, Inspection and Adapt. Scrum promotes Self organization, team collaboration.

Now a days the Industry is going towards Scaling Agile by adopting Scale Agile Frameworks like, SAFe, Spotify, Nexus, DAD, LeSS etc. However Scrum is still essential at the team level. Even we are working on any Scaled agile framework, Scrum is required at execution level.

Lets quickly have a quick look at the Scrum life cycle, and then we will talk about each node of the life cycle

Scrum Life Cycle

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.

Scrum
To understand the primary areas of scrum, lets talk about these 5 points.

Requirement / Artifacts

Product Owner have the vision of the product and creates those requirement in product backlog in form of User Stories.

The Scrum team commits the prioritized user stories at the beginning of each sprint based on the capacity, and creates Sprint backlog. The sprint backlog items  are the set of requirement, that the development team will work on for the specific sprint/iteration to full fill the goal of the sprint and add values to the product Owners vision by making potentially ship-able product increment.

Burn-down chart is another artifact of Scrum, where may people believe to have Definition of Ready and Done is also artifacts of Scrum.

Team / People

The primary role in Scrum are Product Owner, Scrum Master, execution team

Process

The process here is the Ceremonies the team will follow, like Sprint Planning, Backlog Grooming, Retrospective, Sprint Review etc.

Tools

The Tool a Scrum team can use to manage their Agile life-cycle management, like Jira, Rally, Version One, Excel etc.

Engineering Practice

The Engineering practice the construction team will use to develop like XP, TDD, BDD, etc

Lets talk about the above topics in detail.

Requirement / Artifacts

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.

Sprint Backlog

Sprint Backlog is subset of the Product Backlog Items (PBIs) selected for a specific sprint. As we know each sprint have a time box, At the beginning of a sprint the scrum team selects set of PBIs which meets the Definition of ready and in top priority. Keeping in mind the capacity of the Scrum team.

A Sprint Backlog lasts for the duration of the sprint, it forms on the first day of the sprint and dissolves at the last day of the sprint. the Completed PBIs goes back to Product Backlog with “Closed” State and Incomplete PBIs goes back to Product backlog as “Open” state.

The team forms a new Sprint Backlog for the next sprint during the Sprint Planning meeting.

To understand the formation of sprint back, refer the image below. Its explain the formation of two sprint backlog for Sprint 1 and Sprint 2

The Items of sprint backlog or product backlog can be

  • User Story
  • Technical Spikes
  • Bugs

But in Sprint Backlog, You may have two more items those are called Sub-Tasks or Sprint Defects

Each Backlog Items have a workflow path to travel, starting from New to Done. for an example a workflow for a user Story can be

New – Committed – DevInProgres – TestInProgress – Review – Done
or
New – InProgerss – Done
or
New – Analysis – Construction – Review – Done

For Sub Task you can simple have To-Do — In Progress — Done
or the way you think best fit your need

We will learn more about sprint backlog at the section of sprint Planning

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

People (Scrum Roles) 

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.

 

Scrum Ceremonies 

Scrum Framework is designed with couple of collaboration meeting to encourage working together.  This collaboration are kind of meeting where the entire team comes together physically or digitally to fulfill some purpose.

Each of this meetings are called Ceremony in Scrum. and each ceremony have a purpose. Will learn more about these ceremony in details here.

The list of ceremonies are as below.

  1. Capacity & Sprint Planning
  2. Backlog Refinement / Grooming
  3. Prioritization
  4. Daily Scrum Call
  5. Sprint Review
  6. Sprint Retrospective

Lets try to understand these ceremonies in detail.

Capacity Planning

Planning the Capacity means estimate and calculate the capacity of Agile team. There are two widely used capacity measurement units

1. Story PointsThis is Simple way to calculate the velocity (Average of last 6 to 10 Sprint’s Accepted Story Points). and target the upcoming Sprint to commit the User Story that closely match with the velocity.

I Personally recommend the other way of doing the capacity planning by calculate it by Hours.

2. Hours I personally recommend Capacity Planning by Hours. I will explain only on this way of Capacity Planning in this Article. Its gives better visibility and accuracy.  And many other benefits that we will discuss later in this article.

Here we Calculate the available bandwidth of the Agile Team (except PO & SM).  By calculate their available hours for the upcoming Sprint.

Will discuss in details about who to calculate it, what are Factors we should consider in this article.

Lean more and in details about Capacity Planning

Sprint Planning

In Scrum, we have multiple time boxes called Sprints or iterations. In each Sprint bunch of functionalities in the form of stories are implemented to make incremental enhancements to the product under development. The Sprint Planning meeting is the kickoff meeting for each Sprint. This meeting helps set the context of the sprint by scoping the product owner goals for this sprint. It also prescribes the priority for the stories, based on available bandwidth/capacity to meet the goal and deliver the incremental value to the product.

Learn More and in details about Sprint Planning from the below article and Video.

Backlog Prioritization

Product Backlog prioritization is one of most important exercise in agile software development.  Any projects is successful if the stakeholders or clients or business gets most valued functionality at earliest. And that is possible by effectively and consistently prioritizing the requirements (users stories).

Backlog prioritization is required to organize the product backlog items (user story/Defects/Spike etc) to make the sequence of its development and deployment.

This Sequence  is followed by the scrum team to choose product backlog items during grooming or sprint planning.

The influencing factors for prioritizing product backlog items are

  1. Customer Satisfaction
  2. Business Value
  3. Complexity
  4. Risk & Opportunity
  5. Cost

Learn More and in details about Backlog Prioritization from the below article and Video.

Backlog Refinement / Backlog Grooming 

Product Backlog Grooming, Its a most useful ceremony for the scrum teams to define the stories, by maturing up its content, clarify doubts and questions, size relatively And make the story ready to start working on it any time. Most of the team/organization get the benefits of grooming by conducting this ceremony religiously, however few teams/organization still in a debate of using it, or not giving enough importance to this ceremony. A team can achieve a well maintained healthy product backlog by conducting this ceremony effectively and regularly.

 

This ceremony is also known as Product Backlog Refinement or Product Backlog Management

 

In this Article and video tutorial we will learn every details of Product backlog grooming, Team members role in Grooming , whats are the benefits, Insights and Action item in the Product backlog grooming, How to Measure effectiveness of Grooming, What exactly we do in Grooming, etc.

Learn More and in details about Backlog Refinement / Backlog Grooming from the below article and Video.

Daily Scrum 

Daily Scrum meeting is also called can Scrum call or Standup meeting. This meeting own by the Scrum team, happens mostly during beginning of every day. Should last for max 15 minutes. Where the development team member discuss on the work they have done, and make the strategy to work for the day. The highlight the impediments if any. This meeting ideally take place at same time and same place.

For a co-located team all the participants stand in-front of the physical scrum board (ideally the task board) and talk story by story or person by person, Scrum Master facilitate and take ownership of any impediments or provide updates with presence of PO.

Though its majorly known as daily scrum call, both Scrum and Kanban team ideally conduct this agile ceremony.

We will discuss in details of the daily scrum call on each and every part of it in this article.

Learn More and in details about Daily Scrum from the below article and Video.

Sprint Review Meeting

Sprint Review Meeting also known as Sprint Demonstration usually held on the last day of the sprint to demonstrate the accomplishment from the specific sprint commitment. Product Owner from many Agile practices, also review the completed story and mark them as Done or Not Done based on “Definition of Done”. This Meeting is the realization  phase of the each sprint cycle.

This is an Informal meeting, No need to prepare Power point slides or any presentation.

This meeting also supports Agile framework as Empirical Model, by Inspect and Adapt. Inspecting the Product Increment and Adapt the Product Backlog.

There is no defined rules for this meeting, But the meeting has to happen during end of every sprint to have the green signal from the Product Owner or stakeholder for the potentially ship able increment, which was constructed during the sprint.

Learn More and in details about Sprint Review Meeting from the below article and Video.

Sprint Retrospective Meeting

Sprint Retrospective the one of the important ceremony of your sprint cycle, Its usually very common on Scrum framework, many teams also conduct this ceremony for their Kanban practice on a regular interval.

Generally this meeting takes place after sprint review meeting and before the sprint planing of next sprint. If you want to conduct your meeting for your kanban cycle, you can define a interval like every 15 days to schedule it.

This meeting enables the feedback loop to achieve continuous improvement. No matter how mature your team is, opportunities of improvement is always there. This meeting gives the freedom to all member your team to speak about what they feel can be improved, or what they feel can be stopped. This meeting also enable the empirical model by inspecting the process from transparent input and adapt opportunities of improvement.

The main difference of sprint review and retrospective is, Sprint review talks about the achievement, upcoming works for the functional increments, more about the product. where retrospective highlights more about the process like. “Resolution of cross functional dependencies” can be improved, “On-time joining on daily stand-up can be improved”. etc

We will talk about details about, How we can conduct Retrospective, Different ways of Doing Retrospective, Tools you can use to do your retrospective, how to capture and work on the action item of retrospective.

Learn More and in details about Sprint retrospective Meeting from the below article and Video.

Other Key Areas of Scrum

There are other pillars of scrum that are very important to understand

  1. Estimation
  2. Requirements
  3. Visual Boards (Scrum Boards)

Lets try to understand these ceremonies in detail.

Scrum Estimation

We definitely need estimation to plan our software development, in agile we do estimation in little different way than traditional effort estimation, its easy, interesting and yes effective too.

In Agile Estimation we can estimate at its different hierarchy item ( read about story hierarchy ), in this article we are focusing on estimating user stories and its tasks.

Traditionally we use to estimate efforts to develop a functionality, where in agile we estimate Business values or Complexity of a user story level. And estimate efforts in Task level. The unit of estimating user story for its value or complexity is story points, and the unit of estimating a task for its effort is Hours.

We usually relate T-Shirt sizing with Story sizing to mark the relative difference between user story size, e.g., Extra Small , Small, Medium, Large, Extra Large etc, We will discuss about story points in details, later in this article.

The below diagram will help you under stand story level estimation and Task level estimation.

Learn More and in details about Agile Estimation from the below article and Video.

Scrum Board

A Scrum Board is a physical or virtual space that represent the scope of current sprint and its status. The current scopes are broken down into executable tasks during sprint planning. A Scrum board mostly have the stories and its associated tasks. This boards are often called as task board as well.

Its also called as Sprint Board or Task Board

Physical Scrum Board

Mostly co-located Scrum Teams, keep all the committed product backlog items along with the tasks for a sprint, in a board, or even on a wall. Any space that can be used as a flat vertical space, and accessible to the development team

Virtual Scrum Board or Digital Scrum Board

A Virtual Scrum Board or Task board is same like your physical board. But its programmatically generated and rendered on your screen. It has the capability to share on multiple user screen with real time update of other member’s change. Typically a distributed scrum team use a virtual scrum board, as single physical board is not accessible to everyone.

Modern days ALM Tools like, Rally, Jira, Version One, TFS etc provides one or many screen with extensive customization facility to prepare the virtual Scrum Board.

Learn More and in details about Scrum Board from the below article and Video.

Physical Scrum Board

Agile Requirements

In Agile Software development, the execution level requirement or functionality is terms as user story. A user story can be of one or more sentences. The requirement (details contents) in the user story needs to be sufficient enough so that

  1. A developer can start and finish his development
  2. A tester and test the developed code to check if it is meeting the required functionality
  3. Product owner/ BA / Stake holder can verify the desired functionality to accept the story completion.

Each story has be to fulfill a requirement with a very specific goal or benefit, it’s always advisable to break any store to smaller stories, if it has more than one goal.

Requirement of a story has to be of a complete functionality, means upon completion of development, testing and acceptance, the code should be deploy-able, or park for future release. In other word the each user story should be potentially ship-able.

Size of a user story is measured in story points (Refer our section Estimation Techniques), to provide a business value or complexity.

Learn More and in details about User Stories from the below article and Video.

SCRUM REPORTING

Though Scrum is for continuous Development and Delivery, There are some reports we can create sprint over sprint, which we will cover under some different article. here are list of some reports you can think about.

  1. Grooming Updates
  2. Sprint Planning Summary
  3. Mid week Progress Summary
  4. Sprint closure summary
  5. Retrospective Action Item

SCRUM METRICS

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

Hope this page was able to provide the information you were looking for, In case we missed something, feel free to leave your comments, feedback and suggestions, at bottom of the page’s comment section.

Author(s) of this article

Niladri Mahapatra

Leave a Reply