Agile - Scrum - Time Boxing Approach

Time-Boxing in Scrum Methodology

Time is the most important factor in everybody’s life and the same applies to the Projects. The problem is that we don’t use it efficiently, in fact worst possible way.

In the Scrum methodology, time is the prime factor driving all the project activities. Once decided on the time required within Scrum, timelines are fixed and is an alternative option to Scope-boxing. It helps in creating a focussed environment within the team where every team member understand the sense of urgency. Time-boxed approach facilitates the team interaction and implementing control points. The Sprint meetings should be time-boxed and should be followed unfailingly to reap the benefits.

Choosing an appropriate Sprint length is the crucial factor in the success or failure of a Sprint. One needs to consider the various factors to decide the Sprint length.

• The Product Owner’s confidence in the Development team and work effort required from them.


• When does a Product Owner (PO) want to see the finished Sprint product for making decisions.


• The number of Sprints required to make things right before the release.


• How much time will be taken to create something of significance.

There are various benefits of following time-boxed approach in the Scrum methodology,

• More focus


• Predictability increases


• Automatic evolution of the team, no command


• Prioritising and self-organising teams


• Establishes rhythm


• Imparts the confidence and factor of possible.

Follow and Like us:

Agile - Scrum - Time Boxing Approach

Software Testing Metrics

Test Metrics are important to quantify the quality of software testing. Let’s discuss some of the common Test Metrics.

Defect Density (%)

It’s the number of defects per thousand lines of code and shows the quality of the application code. Defect Density should be very minimal. Higher the %age of Defect Density, lower the confidence in the software quality. It can also be calculated in terms of – Module(s) or Requirement(s).

Defect Density = (# of Defects / KLoC) * 100



Defect leakage (%)

It is measured to identify the number of defects missed in the software testing phase.

Defect Leakage =  (Defects found in the ‘N+1’ testing phase / Defects found in the ‘N’ testing phase) * 100



Test Cases – Passed %age

The number of test cases passed in the execution phase divided by the total number of test cases.

Passed %age = (# of test cases passed/total # of test cases executed) * 100



Test Cases – Failed %age

The number of test cases failed in the execution phase divided by the total number of test cases.

Failed %age = (# of test cases failed/total # of test cases executed) * 100



Test Cases – Blocked %age

The number of test cases blocked in the execution phase divided by the total number of test cases.

Blocked %age = (# of test cases blocked/total # of test cases executed) * 100



Test Cases – Execution %age

The number of test cases executed in the phase divided by the total number of test cases written or available for test execution in the corresponding phase.

Test Execution %age = (# of test cases executed/total # of test cases available) * 100



Test Case Writing Productivity

The Productivity factor is often talked about and measured by considering total number of test cases written in a particular timeframe.

Daily Productivity (Test Case Writing) =  Total # of Test Cases written / # of hours in a day



Test Case Execution Productivity

The Test Case Execution Productivity is measured by considering total number of test cases executed in a particular timeframe.

Daily Productivity (Test Case Execution) =  Total # of Test Cases executed / # of hours in a day



Defects – High Severity %age

This metric gives a quick idea about the high severity defects out of total identified.

High Severity %age = (# of high severity defects / total # of defects) * 100



Defects – Med Severity %age

This metric gives a quick idea about the med severity defects out of total identified.

Med Severity %age = (# of medium severity defects / total # of defects) * 100



Defects – Low Severity %age

This metric gives a quick idea about the low severity defects out of total identified.

Low Severity %age = (# of low severity defects / total # of defects) * 100



Defects – High Priority %age

This metric gives a quick idea about the high Priority defects out of total identified.

High Priority %age = (# of high Priority defects / total # of defects) * 100



Defects – Med Priority %age

This metric gives a quick idea about the med Priority defects out of total identified.

Med Priority  %age = (# of medium Priority defects / total # of defects) * 100



Defects – Low Priority %age

This metric gives a quick idea about the low Priority defects out of total identified.

Low Priority %age = (# of low Priority defects / total # of defects) * 100

Follow and Like us:

Software Testing Metrics

Project Managers Compromising Testing Processes

I’ve come across an interesting situation few days back which reminded me few other instances also.

‘Sometimes, why do PMs start compromising testing processes to accomplish project targets or to sort out other issues. Is this approach beneficial for the project?’

I’ve encountered this approach many times and most of the time the reason is to meet the timelines or covering the delay happening on other project processes. Only Test Manager or Test Analyst can understand the existing Testing stage and should take a strong stand against it.

For example, there was a scenario where PM was requesting to go into the Production without Test Sign-off to cover the time being spent on other processes. This is totally unacceptable and away from the basics. If we are going live without Test Sign-off then that’s a big gap in the software life cycle process. Absence of Test sign-off means no input from the Testing team on the software quality, which signifies no value put on the Software Testing. We should not compromise Testing processes to sort out other project issues.

Under no circumstances the IT testing should be compromised, it is the core for the measurement of the project’s deliverables.

Follow and Like us:

Project Managers Compromising Testing Processes

Agile Scrum – Sprint Review Facts

• A feature should not be demonstrated in the Sprint Review if it doesn’t meet the Definition of Done (DoD).


• Always explain the context around the features to be demonstrated to have everyone on the same page.


• The Product Owner accepts only those features which were agreed at the start of a Sprint and met the Acceptance criteria.


• The Product Owner decides whether the features demonstrated in the Sprint Review are ready for release or need more work on it to bring it to the release-ready standard.


• The preparation time for the Sprint Review must not be long. Team can have a quick planning session and identify what to demonstrate.


• Sprint Review is a primary platform to collaborate and understand the progress of the software. The constructive feedback is always welcome.


• Stakeholders can provide a valuable feedback in the Sprint review sessions.


• The Sprint Review session involves demonstration of the features, discussing acceptance criteria, to elicit feedback and what could be the implications on the future Product Backlog Items (PBIs).


• The features should be presented as a Team achievement rather than an individual. Encourage Team Work.

Follow and Like us:

Agile Scrum – Sprint Review Facts

PRINCE2 – Controlling a Stage (CS) | Delivery Stages

The First Delivery Stage or Controlling a Stage is where the team gets involved and the Project Manager (PM) does most of the work.

• PM assigns Work Packages to the Team Managers and keeps track of the progress till completion.


• Shares regular reports to the Project Board about the progress.


• Compares the current status with the Stage Plan.


• Manages issues and risks.

Managing a Stage Boundary (SB)

The Stage Boundary process comes into the picture at the end of CS stage and involves preparing documents about the work done in the stage.

• Business Case and Project Plan are updated with actual information.


• End Stage Report talks about the comparison to the actual plan.


• Next Stage Plan presents an overview about the next stage to the Project Board for approval.


• Benefits Review Plan summarising if benefits have or have not been realised.

Project Board reviews all the information presented and compares the progress along with the benefits with the actual plan and decides if it’s still viable to go ahead with the project. The Next Delivery Stage is started only once the Project Board give its approval.

The timelines for this stage vary from project to project but can be around 8-10 weeks.

Multiple Delivery Stages

The Project can have 2 or more stages and all preceded by the Project Board decision. All the above activities in the 1st Delivery Stage are duplicated in the next stages except the Work Packages. Other difference could be the change in timeline as per the project situation but approved by the Project Board.

Follow and Like us:

PRINCE2 – Controlling a Stage (CS) | Delivery Stages