Types of User Stories

Following are the most common types of user stories used in the industry:

  1. Regular User Story: A typical user story written around a functional or non-functional requirement which can be completed in one iteration(sprint). It can be written by anybody in the team but defined and prioritized by the Product owner.
  2. Technical Debt Story: Normally developed by technical staff and is used to address accumulated technical debt (refactoring, new approach, incomplete implementation, etc.)
  3. Spike Story: A research user story to gain knowledge about the unknowns in a new piece of functionality before creating regular user stories for implementation. It always carries 0 story points but carries hour estimates to quantify the effort spent on it.
  4. Research Story: It’s is a story with 0 story points to gain Broad, foundational knowledge about a new requirement which may lead to multiple user stories.
  5. Tracer Bullet Story: A very narrow but deep implementation (aka “slice”) of production quality. Also called proof of concept(POC). May contain very little story points.


Like my blog?


Agile Myths

Several Agile myths have been floating around in the industry. Below listed are some of the common ones:

No Planning

  • Agile methods generally conduct more planning than traditional methods starting from

Vision > Roadmap > Release > Iteration > Daily planning (daily Standup)


No Estimating

  • Agile methods use a different method of determing how long a piece of work will take
  • Relative sizing is used in Agile
  • Sizing happens at story level in story points and at tasks level in hours.


No Documentation

  • Agile Values Working software over comprehensive documentation. Meaning no irrelevant documents. Create documents only if they add value.


No Visibility beyond the iteration

Agile provides broad visibility through the following artifacts:

  • Roadmap plans
  • Release plans
  • Product backlog
  • Release Backlog
  • Release BurnUp/Burn down
  • Team Velocity etc


Agile is a silver bullet

If you have problems with your development team, making a switch to Agile will not fix them, instead it will make them appear to be more broken.

  • Developers that don’t code well will break the build more often
  • Team with poor communication will communicate poorly more often.
  • Defects will be injected more often and quality issues will appear to be everywhere

The value of Agile is not that it fixes your problems, but that it exposes them early enough to allow the team time to get them fixed.


Like my blog? 


Agile Certifications

Agile is being implemented the world over now and thus the demand of people proficient in agile methodologies is also skyrocketing. To meet this need several agile certifications are offered by different organizations, some of the major ones are listed below:

Project Management Institute (PMI) Offers:

  • ACP: Agile Certified Practitioner


Scrum Certifications:

Scrum Alliance offers:

  • CSM – CertifiedScrumMaster
  • CSPO – CertifiedScrumProductOwner
  • CSD – CertifiedScrumDeveloper
  • CSP – CertifiedScrumProfessional
  • CSC – CertifiedScrumCoach
  • CEC – CertifiedEnterpriseCoach
  • CST – CertifiedScrumTrainer


Scrum.org offers:

  • PSD-I: Professional Scrum Developer – I
  • PSPO-I: Professional Scrum Product Owner – I
  • PSPO-II: Professional Scrum Product Owner – II
  • PSM-I: Professional Scrum Master – I
  • PSM-II: Professional Scrum Master – II
  • PSM-III: Professional Scrum Master – III
  • SPS – Scaled Professional Scrum


Scaled Agile Framework (SAFe) certifications:

  • SAFe Agilist (SA)
  • SAFe Practitioner (SP)
  • SAFe Scrum Master (SSM)
  • SAFe Advanced Scrum Master (SASM)
  • SAFe Product Manager / Product Owner (PMPO)
  • SAFe Program Consultant (SPC)
  • SAFe Program Consultant Trainer (SPCT)
  • SAFe Product Manager/Product Owner (SPMPO)   


Xtreme Programming (XP) certifications:

  • Professional Scrum Developer – I (PSD-I) from Scrum.org 
  • Certified Scrum Developer (CSD) from Scrum Alliance


Kanban certifications:

Although Kanban certifications are too famous but Lean Kanban University offers several Kanban certifications. 


Like my blog? 



Types of Agile Methodologies

Agile Software development is a High-Level Term used for all different kinds of incremental and iterative software development frameworks and these frameworks essentially follow the core ideas of Agile development like the 12 point agile manifesto. Some of the most widely used frameworks in the industry which are considered the various types of agile methodologies are:

  • Scrum
  • Extreme Programming (XP)
  • Kanban
  • Lean
  • SAFe (Scaled Agile Framework)
  • TDD (Test Driven Development)
  • ATDD (Advanced Test Driven Development)

These frameworks differ from each other in several ways but the basic values of all of these are derived from Agile Manifesto. All these are iterative and incremental processes which support the idea of continuous improvement. In other words, all these frameworks prescribe to develop the final product in small batches and eventually deliver it as a whole on time and on budget. Also keep improving the process continuously inspecting and adapting to the changes on the fly. And the above listed frameworks also emphasize on the empowerment  and self organization of the team members.


Like my blog? 


Scrum Master Interview Questions

Below are some of the basic Scrum Master Interview Questions to get you prepared for your next one:

What is a daily scrum Meeting?

Ans: It’s a daily 15 minute meeting where the team comes together and every individual on the team (except the ScrumMaster and Product owner) talks about 3 below listed items:
– What they last yesterday?
– What are they going to work on today?
– Any blockers they have?


What are the most important scrum artifacts? And who maintains them?

Ans: Below is the list:
– Product Backlog   (Maintained by the product owner)
– Release Backlog   (Maintained by the product owner)
– Sprint Backlog   (Maintained by the team)
– Sprint Burn down   (Maintained by the ScrumMaster)
– Release BurnUp   (Maintained by the ScrumMaster)


What type scrum ceremonies have you conducted in the past?

Ans: Below is the list:
– Daily Scrums
– User Story Grooming Meetings
– Sprint Reviews
– Retrospectives
– Sprint Planning
– Release Planning


What does a scrum team look like?

Ans: An ideal scrum team consists of:
– 1 scrum master
– 1 product owner
– 5±2 cross functional team members (who can develop and test)

But in real world since its difficult to find cross functional team members, most teams have:
– 1 Scrum master
– 1 product owner
– 3±2 Devs
– 3±2 testers.


What are the different agile management tools available in the market?

Ans: Below is the list of most popular Agile management tools:
– 1 Scrum master
– Rally
– TFS (Team Foundation Server)
– RTC (Rational Team Concert)


What is the difference between a Sprint and an Iteration?

Ans: Sprint and iteration are one and the same thing. No difference at all.


What is the difference between a Product Owner and a ScrumMaster?

Ans: Please refer to – Product Owner and Scrum Master


What is a scrum board?

Ans: Its a board which lists all the user stories and defects in the current sprint with their current statuses. It contains different columns like:
– In Analysis
– In Dev
– In QA
– Done!
Scrum Board can be a physical board or a virtual board in one of the agile management tools like JIRA, Rally etc.
One scrum board per team.


Why scrum framework prescribes Dev team members to be cross functional?

Ans: Since scrum prescribes to run all the activities (Analysis, Dev, QA, UAT, deployment) in parallel for individual user stories within a sprint, its best to have cross-functional team members who can Develop and test.


Difference between Epics, User stories and tasks?

Ans: Epic – is a high level requirement which can be broken down into smaller workable pieces to fit within an iteration. An epic contains several User stories.
User Stories – are the requirements which are broken down to such a small level that they can be completed in one iteration. A User Story can contain several tasks.
Tasks – A task details out what needs to be done to complete a user story. Like There can be Dev tasks, QA tasks, Analysis tasks etc. Every task has estimated number of hours (to complete that task) attached to it. So the total number of hours on all the tasks for a user story can give the estimation of how long it will take to complete that user story.


What is Velocity?

Ans: The total points for the number of stories marked done in a sprint/iteration of a team are considered as the velocity of that team for that specific iteration.


How is Average Velocity calculated?

Ans:Typically we take velocity of past 3 iterations and calculate the average velocity by using the following method:
Average Velocity = V1 + V2 + V3 / 3
V1= Velocity of sprint 1
V2= Velocity of sprint 2
V3= Velocity of sprint 3


What has been the average velocity of your past teams?

Ans: Velocity differs from team to team so its very specific to your past experience.


What was the highest and lowest Story points you used in your past projects?

Ans: The lowest typically can be ‘0’ or ‘0.5’ but the highest totally depends on your team. Use your past experience to answer this.


How can you standardize the velocity across all teams in an organization?

Ans: Standardizing the velocity across all teams may not work out very well as different teams work on different type of work and they may not have enough similarities in their work to standardize the story pointing. Also we must not forget points that different teams may have different velocities based on the way they point their stories but that doesn’t not necessarily mean that team with higher velocity is performing better than the team with lower velocity.


How can you know the velocity of a newly setup team and how to plan work for that team’s coming iterations?

Ans: Teams commit to an amount of work for a sprint/iteration based on their average velocity. But a new team doesn’t have a set average velocity so for the first sprint they go by the gut feel of the team.
Based on the team members past experience they can tell how much work they can accomplish in a sprint and after pulling that much work in the first sprint they will have to see if that much work was more for them or lesser and based on that experience they choose the amount of work for next sprint and so on.
These learning are discussed in the team retrospectives.


What is a product increment?

Ans: Product increments are the pieces of functionalities that are completed in individual sprints/iterations and added to the product itself.


What is the difference between a BurnUp and a BurnDown?

Ans: BurnUp – It represents story points adding up to the total scope on a graph and it is typically used for showing Release progress (called Release BurnUps)

BurnDown – In contrary to a burn ups it represents a graph of story points starting from the actual scope and burning down to ideally 0 as the days in a sprint go by. Typically used for Sprints (called Sprint Burn Downs)


How do you quantify work in Agile?

Ans: Work is quantified using ‘Story Points’. Every story carries story points and the total effort in a sprint or in a release is the total number of story points on the stories in that specific sprint or Release.


How do you estimate work in Agile?

Ans: Several estimation techniques are available in the industry but the most popular and in my opinion the most effective is Planning Poker technique. Almost all agile teams in the industry use this technique.


What is Planning Poker and how to conduct it?


Who writes the stories and who marks them Done ?

Ans: Any team member can write stories and add them to the product backlog but those need to be well defined and estimated before they get pulled into an actual sprint / iteration.

The typical route of closing stories is that a tester passes the stories after testing and demos them to the Product Owner to mark them Done/Accepted.


What is the difference between product backlog and sprint backlog?

Ans: Product Backlog – All the planned and unplanned work, in the form of user stories, for a product is maintained in the product backlog. Stories in the product backlog may not be ready to be played since they may lack Acceptance Criteria or final estimates.

Sprint Backlog – The list of stories in a sprint is called sprint backlog. Its a subset of product backlog stories but all the stories pulled into a sprint are well defined and estimated.


How can you help your team continuously improve?

Ans: Retrospective meetings provide an excellent opportunity to introspect and find out what are the areas of improvement. Team should make use of this ceremony to continuously improve.


If your committed work doesn’t get completed in a sprint, do you increase the length of that sprint?

Ans: No the time box always stays the same, the remaining work moves over to the next sprint/iteration.


What is a sprint goal? and who sets it?

Ans: Sprint goal is a short term goal set to be accomplished within a sprint. Each sprint can have a different sprint goal. For example: Team X is going to complete all the stories related to a certain functionality.

Team should set a sprint goal for themselves not the scrum master nor the product owner.


What is an Acceptance Criteria?

Ans: The list of functionalities/micro-functionalities to be developed are listed in a user story and that list is called the Acceptance Criteria for that story and it also describes what needs to be developed and tested to mark that story done.


Who writes Acceptance Criteria in the user stories?

Ans: Product Owner writes the acceptance criteria for every single story.


What happens if a user story contains 4 acceptance criteria but developer ends up developing only 3 and misses the 4th?

Ans: A user story does not get accepted until the all the ACs in a user story are developed and tested.


What is Definition of Ready?

Ans: A list of criteria set to determine if a user story is ready to be pulled into a sprint and can be worked on. For example:
– User story is defined
– User story is sized


Similarly what is Definition of Done?

Ans: A list of criteria set to determine if a user story can be marked Done. For example:
– Code produced
– Tested
– Passed UAT
– Deployed


How do you plan for releases?


Like my blog? 


Scrum Master

Scrum Master is one of the 3 scrum roles and the characteristics of an ideal Scrum Master are as follows:

  • Ensures the team is completely functional and productive
  • Helps the team to organize its work by keeping them focused on the sprint goals.
  • Leads the team through conflicts
  • Removes impediments for the team
  • Fosters the team on the path of continuous improvement
  • Protects the team from external disturbances so they can focus on their goals and commitments
  • Helps the team become self organizing by empowering the team members
  • Creates transparency by keeping the scrum artifacts visible to the team and the stakeholders.
  • Creates and manages matrices like burndowns and burnups for the stakeholders’ and team’s reference.
  • Takes care of the Scrum Process by facilitating scrum ceremonies like Daily scrum, demos, sprint planning and sprint retrospectives
  • Makes sure agile ideas are understood and respected by all stakeholders, PO and organization
  • Moderator, Trainer, Mentor and Mediator for the team.

Keys to a successful Scrum Master:

  • Should have a servant’s heart to be ready to help the team in any way possible to make them move forward
  • Should not act as the team’s manager but a leader and a facilitator
  • Should be an expert on Scrum
  • Has decision making authority
  • Actively involved in setting goals for the team including release goals and sprint goals.


Like my blog? 


Product Owner

One of the 3 scrum roles is Product Owner and the characteristics of an ideal Product owner are as follows:

  • Primarily focused on achieving maximum Return on Investment
  • Defines the vision for the product to be developed
  • Creates and regularly prioritizes and refines the product backlog based on the changes in direction of the project
  • Creates release plans and sprint plans to define delivery timelines
  • Single point of contact for all questions relating to requirements
  • Approves user stories to be marked ‘Done’ or Rejects them
  • Makes decision on the direction of the project
  • Represents stakeholders voice and protects their interests

Keys to a successful Product Owner:

  • Has decision making authority
  • Active participant in Goal setting for releases.
  • Has his time dedicated to do the job
  • Available for clarifications and discussions
  • Understands customer needs
  • Has good Scrum Knowledge


Like my blog? 


The Development Team

One of the 3 scrum roles is the development team and the ideal characteristics of an ideal development team are as follows:

  • Small in size: 7 ± 2
  • Resources are dedicated full time to the team
  • Cross functional resources who can analyze, develop and test
  • Self Organizing
  • Empowered and autonomous
  • All resources are co-located
  • Accountable for delivery

Development Team


Like my blog? 


What is a Sprint

Some people like to call it a Sprint and some like to call it an Iteration but in the context of Agile development its one and the same thing.

Sprint / Iteration: A time box during which the actual software development happens. It could last from 1 week to 4 weeks based on the project and this time frame remains fixed for all the sprints i.e. if the first one was 3 weeks then all the consequent ones will be of 3 weeks each too.

Agile coaches say that although you can choose to have sprints ranging from 1 week to 4 weeks but in practice 2 week sprints have proved to be the most optimum.


No changes are made once a Sprint begins, since the team commits to a Sprint Goal so we do not:

  • change the team NOR
  • allocate any other work

Key characteristics:

  • Timeboxed (1-4 weeks long)
  • No disturbances allowed
  • Shippable product increment is produced at the end.
  • Not a mini-waterfall


Inside a Sprint all the following activities happen continuously at all times: 

  • Analysis
  • Design
  • Develop
  • Test
  • Integrate


inside a sprint


Like my blog? 


INVEST criteria

A well written user story follows the INVEST model:

  • Independent – Has less to no dependencies on other stories / teams so its easier to plan for it
  • Negotiable – Team should be able to collaboratively come up with the details of the story
  • Valuable – Should provide some value to the project / customer
  • Estimable – Should not be too vague or too big to estimate
  • Small – Should be small enough to be developed and tested within one iteration / sprint
  • Testable – Should contain well defined Acceptance criteria.

Invest model


Like my blog?