Importance of Daily Scrum Meeting and Sprint Retrospective

Importance of Daily Scrum Meeting

What is a Daily Scrum Meeting?

A Scrum meeting is usually held for Projects that are focusing on Agile Development or a company that is adopted for Scrum practices. Daily Scrum is a meeting that is held every working day, usually it scheduled in the morning and will last for maximum of 15 minutes. It is time-boxed to 15 minutes to keep the discussion short and to discuss only the important.

The Daily Scrum meeting is basically a status update. All the members of the team needs to participate in this meeting including the Product Owner, Scrum Master plus the team.

This meeting is beneficial for the following reasons:

• Building the trust between the team members
• Check the sprint is on track and to get to know whether there are road blocks or impediments to achieve the final sprint goal
• Getting the chance to speak and express your ideas in case someone is having impediments
• Helps you to plan ahead of your tasks.

In this meeting everyone needs answer the following questions:

• What tasks did you do yesterday?
• What tasks are you planning to do today?
• What are the impediments you are facing, if you have any?

This meeting improves the team work, and the individual commitment within the team. 

Importance of Sprint Retrospective

The Sprint Retrospective is held at the end of the sprint, basically after the sprint review and before the start of the next Sprint Planning. This meeting can last for 2 or 3 hours depending on the number of team members and the complexity of the things that will be discussed. This meeting is scheduled by the Scrum Master and in some companies there will be one internal retrospective and  the actual retrospective. In the Internal Retrospective, the Scrum Master and Team will join and discuss all what happened in the sprint in detail and find solutions to problems if there were any. However the Actual Retrospective will be held with the Product Owner, Scrum Master and Team and usually will be limited to discussing the important points. 

During the Sprint Retrospective the team discusses the following:

What went well in the Sprint?

What didn't go well in the Sprint?

What can be improved?

What are the actions that will be taken to improve?

This meeting will help to improve the trust between the team, compliment each other for their hard work, Help out each other who was having impediments and to ensure that everybody is part of a team and no one is alone. 

This meeting will improve the quality of the product as improvements are discussed and the actions are noted to be taken, and will be practiced from next Sprint on wards. 

How to do Regression Testing in a SCRUM Project?

What is Regression Testing?

In simple words regression testing is testing again what has already been tested. This testing is done when a modification, code changes or a new functionality added to the system. We do this testing to ensure that the modification will not affect the existing functionality which was perfectly working fine earlier.

When to do Regression Testing?

Whenever a modification is done, it is not feasible to do regression testing. So we have to come up with a plan. If we follow agile we can break several tasks for regression within the Sprint and we can carry out regression testing based on the milestones defined within the sprint. (Eg: Milestones: A date when a specific functionality or two being released and tested). This will ensure the existing functions are working as expected despite there are modification done time to time. If Waterfall once a modification is done to an existing functionality , better to do regression testing for that affecting module only.

You will have to run through all the test cases that's been executed so far which is related to that module and do a high-level testing based on those test cases.

Some Regression Testing Examples (When we need to do regression testing?)

1. When new functionality is added to the system
2. When there is a Change Request
3. When there is a modification in code

However, it is up to the team to plan the regression testing properly without doing it all the time.

I have noticed some teams doing regression testing at the end of the UAT cycle saying they are covering all the end to end test cases. However, it is not how the way it should be done. The testing you do after an UAT cycle which caters end to end is basically system testing.

However different teams follow different methodologies and they have different definitions for these testing approaches. This way I mentioned is what I practiced for a long period.

How to write a Test Scenario?

What is a Test Scenario?

According to my understanding, one functionality can have many Test Scenarios and one Test Scenario can have many test cases. We are writing test scenarios or keeping track of test scenarios because it is an definite aid for our End to end testing. For end to end testing we cannot be executing all the test cases, so we have a set of test scenarios covering all the functionalities in a high level way.

How to prepare Test Scenarios?

Go through the functional spec or the backlog item and determine all the use cases or basically high level scenarios that you have to test. Basically you figure out these first and narrow down the test scenarios to test cases.

Example of How to come up with Test Scenarios for a particular functionality?

Assume the functionality you have to test is purchasing Unit trust which can be Lump sum or Monthly and which can be paid using different payment methods like Cash, SRS or CPF? Minimum amount for purchasing is $1000. Purchased funds are visible to customer.

So basically you can come up with following test scenarios:

• Purchase Lump Sum unit trust
• Purchase Monthly unit trust
• Purchase both monthly and Lump sum unit trust together
• Purchase unit trust with different payment methods
• Can't purchase due to Account having not sufficient funds

You can derive test cases as the following:

• Verify Lump Sum field only accepts numeric
• Verify Lump Sum field minimum should accept $1000
• Verify Monthly field only accepts numeric
• Verify Monthly field minimum should accept $1000
• Verify when Lump Sum unit trust is purchased, it is displayed to customer
• Verify when Monthly unit trust is purchased, it is displayed to customer 
• Verify the records in backend whether purchase successful
• Verify pay with Cash
• Verify pay with CPF
• Verify pay with SRS
• Verify pay with Cash/ CPF/ SRS when customer don't have the relevant account
• Verify the error message displayed when customer don't have sufficient funds
• Verify purchasing unsuccessful screen

Hope this article helps to identify the differences between Test scenario and Test case.

How I practiced Scrum as a QA member?

The Scrum Process I followed

First of all the client is going to create a Product Backlog using Visual Studio Team Foundation Server. The Product Backlog includes all the Backlog items that should be implemented. Backlog item is a specific user story which includes the acceptance criteria for that particular user stories. Like that 100+ backlog items will be there in the Product Backlog.

Prioritization of Product Backlog Items 

The product owner or client will prioritize the backlog items based on the urgency of implementation. Once the backlog items are prioritized the Scrum Master will take several prioritized backlog items to a Sprint. 

What is a Sprint?

A sprint usually will be timed for one month or less than a month. I followed 21 working days Sprint. At the end of a Sprint an usable and potentially releasable product will be released to the Product owner or client. This product we create is incremental and iterative. It will take a few more sprints to complete the Product with all the functionalities yet each Sprint delivers a workable product to customer. A new sprint will start immediately after a Sprint is finished.

Task Breakdown and Task Estimation

The Scrum Master will assign prioritized backlog items for each sprint. Then the team as a whole will divide tasks for each backlog items. Each backlog item will have 2 or 3 development tasks and one QA task. Then the developers will be estimating the hours for each development task using planning poker technique also the QA task will be estimated by QA members in the team using the same planning poker technique. 

Note : This task breakdown and task estimation is done on the Day 1 of the Sprint. 

Buffer time and additional QA tasks per Sprint

Additionally to the tasks breakdown for each backlog item that are taken into the sprint, the team will create few more tasks for QA. Eg: Performance testing task, Integration testing task, Regression Testing task, Automation Testing Task, Test case Creation Task and Test case Review task. Also developers will have their own common tasks created. All these tasks will be estimated using planning poker technique. Usually there will be one internal demo task, Sprint Review task and Sprint Retrospective task included within the sprint. 

Usually team decides how much buffer time needs to be included within a sprint because we never know what will go wrong within a sprint. Buffer time will usually be 1 or 2 days within a Sprint.

What is Sprint Retrospective?

This meeting is normally hosted by Scrum Master. It usually takes place after the Sprint Review and before the next Sprint starts. During the Sprint Retrospective, the team discusses:

• What went well in the Sprint?
• What could be improved?
• What will we commit to improve in the next Sprint?

What is Daily Scrum Meeting?

The Scrum Master, the team and the Product Owner usually sits for this Daily Scrum Meeting. 

During the daily scrum, each team member answers the following three questions:

What did you do yesterday?

• What will you do today?
• Are there any impediments in your way?
• The impediments will be discussed offline after the Scrum meeting.

If any questions happy to answer more!