The Retrospective

 I always tell my children to go through the previous question and answer sheets (upon receipt of the latter), to understand and retrospect, what they did good and what not. It gives a good indication of their strong areas, find out improvement areas and hence work on course correction. That's an examination retrospective.

Now, how many times have we argued and discussed at length about the 20:20 cricket matches post completion? 

When it comes to Sprint, alas, the retrospective is not given its due importance. That 30 minutes in your sprint timebox is an investment. What should be done for an effective retrospective?

 1. Plan a retrospective: (ie) Send the invite and the online form, where team members can mention the good and the bad (as cards) and even encourage the team to vote those items. That way you know which are your top issues and top winning strategies.

 2. Conduct the retrospective: Encourage participation. Sometimes the leads or managers and senior team members may be more vocal than the junior members. Give opportunities for them to speak up. Ask their views. Key points to note in a retrospective are:

  a. Do not make it emotional. 

  b. Follow a blameless culture.

 3. Act on those Action Items: The key for the success of a retrospective is that the team members should know that their voices have been heard. Concerns should be noted and translated to action items. Action items should contain owner and ETA. Actions should be acted upon and the team members should see those actions implemented in the upcoming sprints. This gives team 'Hope'. It creates 'Trust'. They feel 'Important'. All necessary for employee satisfaction.

Time to check the calendar guys - block the time for the retrospective!

The Anti Patterns in Scrum

There are certain practices that we do in scrum that are counter productive. These practices are called 'Anti Patterns'. Here in this blog, I have discussed some of those perils in Scrum teams.

Team Size: Scrum manifesto clearly states that the Scrum team size should not be more than 9. It is even better if it is of lesser than 9, but definitely not more than 9. Rightly said as the scrum team members should all know what every other person is doing. They need to work hand in glove! This is only possible when the team size is less. A team of size 'n' has n*(n-1)/2 communication channels. In the figure below we see that a 5 member team has 10 communication channels. 

• 1 talks to 2, 3, 4,5 and vice versa = 4 channels
• 2 talks to 3, 4, 5 and vice versa = 3 channels 
• 3 talks to 4, 5 and vice versa = 2 channels
• 4 and 5 talks = 1 channel.

If it were a 10 member team, imagine the chaos. we would have 45 channels of communication and it would be a herculean task to know what each team member is doing.

So keep the size to 5 to 7 members.

Changes within a sprint: Sprint is a short burst of work period. It has a well defined goal. The main essence of the scrum model is to analyze priority, ship it to customers quickly and get early feedback. Changing the scope or changing team members will have a negative impact on meeting the sprint goal. A clear anti pattern that you may want to avoid.

Ignoring the retrospective and its actions: The most important scrum ceremony in my opinion is the retrospective. This is because, we talk on the actual data. What actually worked and what let us down. It helps us as teams and as individuals to understand where we went wrong and self improve. It's an immediate feedback. Where else do we get it? Half yearly or yearly manager feedback? Really, do you want to wait a year to know what worked and what not? Conducted correctly in its spirit and working on its actions will see the teams only performing better and better. Participate, be vocal.

Lack of cross functional team: The scrum team should have developers, QAs, the availability of product owner, architects etc to perform their work seamlessly and independently. It is also very important to have every developer and QA backing up each other, so that on emergency situations, the other Dev/QA can pick up the work. That is precisely the reason why each team member should know what the other is doing and forms the basis for the team size.

Delayed testing, bug fixing: Testing, raising and bugs and fixing should be done within 24 to 48 hours of the code being sent to the QA for testing. Why is that so? The code logic is still afresh in the developers mind. Remember that in all probabilities, its a very complicated logic, where changing a single boolean value could wreak havoc. Strike while the iron is hot - give the bugs to the developers when the logic is very fresh in their minds and therefore rework/fix can be done very fast. 

There are many more - like the unavailability of the Product Owner, having a poor definition of done, having hierarchies in a team (note that scrum team has only 3 roles, the scrum master, product owner and the team) etc. We need to be aware of these anti patterns, educate the scrum teams about it to build a highly productive and collaborative team.

The Burn Up Chart

 For a long time, I was satisfied and there by used only the Burndown charts to track progress of sprints. This is until I read more about the Burnup chart and the whole gamut of values that it brings.

What is a Burn Up Chart?

You want to track the progress of your sprint every day. (ie) you want to know how many story points you have finished on each day and how many are left out to complete the sprint. You have decided to track it in the form of a chart. A Burnup chart does this exactly. We plot the number of story points completed each day and there by see how good/bad we are in a position to complete the story points within the sprint timeline.

The advantages of this chart are:

1. It shows any scope changes immediately, unlike a burndown, where it can be easily missed. This is very useful in identifying scope creep, as the chart always shows the changed scope at the top of chart, which the team would then know that as either 'scope creep' or revised target for that sprint

2. It helps Product Owners to understand the velocity and help visualize the day of completion if a few story points are to be added.

Now if you see the graph below, the above points can be inferred easily and quite accurately.

3. The other way to see the burn up chart is that we can measure the value delivered along with the story points delivered. Remember that in scrum, the result is not based on # of stories or # of story points, it is rather the amount of value that we deliver.

Assuming that in the above scenario of 50 points we have 10 stories, 5 with high values (5 points each) and 5 with low values (2 points each). The net value to be delivered in this sprint is 35. Again using this chart the total value delivered at a given point of time can be found.

How to write a good User Story?

Until User Stories came into existence, requirements, in my opinion hardly spoke about the person who needs it or why the person needs it. It was impersonal.

The good thing about Agile User Story is that it tells who wants it - is it an Admin who needs it? is it a data operator who needs it? And it also tells why it is required. That is the key - The 'why' gives the developer or a tester the 'value' or the importance of doing that story.

Scrum is all about delivering value. The user story should talk about it. How else can the person developing or testing it will get a sense of importance of the work he/she is doing?

User story should tell us the below details:

• Who wants? The Persona
• What do they want? The task to be done
• Why they want? The value
• And then how do I test and Accept that its done, once the story is completed?

That is all that is required in a Story!

Eg:

As a shopper, I want to be able to search for any product and also be able to apply filters, so that I can find the specific items that I am looking for.

Acceptance Criteria:

1. Search button and search text box should be visible clearly. 

2. User should be able to enter the data in search box

3. Filters should include options for Prize, Size, Color

4. On clicking the apply filter, search results should change appropriately

Now a good Story should also follow the INVEST principle.

I - Independent - It can be independently shipped to Production.

N - Negotiable - A story is not a signed contract. Its subjected to change. It should be flexible. In the above example, if we need to add another filter, we can/should be able to do it.

V - Valuable - It should have a purpose

E - Estimable - We should be able to give an estimate

S - Simple 

T - Testable - Able to test and accept its completion

Some Important Cost Metrics

When it comes to cost analysis, the below formula and examples would be very helpful.

Scenario: My budget is Rs 1000. Project schedule = 4 weeks of which 3 weeks are completed.

Earned Value:

This is the value of work that is already completed. Assume that 70% of the work only is completed.

Formula: EV = % Work done * Budget. 

In the above eg: 70/100 * 1000 = Rs 700

This is a very critical value. How do I find how much of work is completed in various Software life cycle phases? Here is an example. Assume that we have 5 requirements, of which 2 are simple (estimated design time is 3 days each), 2 are medium (estimated design time is 5 days each) and 1 complex (estimated time is 10 days). Total estimated time to complete design work = 26 person days.

1. Design Phase Earned Value Scenario 1: If 2 medium and 1 simple are completed, then 13/26 is completed (ie) 50% is completed.  
2. Design Phase EV Scenario 2: If 2 simple and 1 medium are fully completed and the complex is 'In Progress' and the other medium is yet to be started, then the amount of work completed can be calculated based on the below:
1. Based on the break down of the complex requirements' design into UI design, backend architecture, API endpoints or db schema etc., and the work completed in each of these items, we can give an approximate work completed. Although it may not be accurate, this approach will help to give us an idea of work completion to a very good extent. So in this example, if we have UI design and db design each spanning 3 days and the backend requires 4 days, if UI alone is completed, we can say that 3/10 is completed. Therefore total work completed in this scenario = 3 + (3*2) + 5 = 14/26

Test case execution earned value is direct, as we would know the total number of test cases to be tested and the number already executed/tested. 

On the other hand, for test cases write up work, based on the number of the test scenarios completed for each functionality we can give the work completed details.

_______________________________________________________________

Planned Value:

This is the value of work that we planned to complete by that time. Eg: We want to complete 75% of work by end of 3rd week in a project spanning 4 weeks.

Formula: PV = % Planned work completion * Budget

In our example: PV = 75 * 1000 = Rs 750

_______________________________________________________________

Schedule Variance:

Formula: EV - PV 

In our example: 700 - 750 = -50 (Which means we are behind the schedule)

Schedule Performance Index (SPI):

Formula: EV / PV

In our example: 700/750 = 0.93 (A value < 1 implies that we are behind the schedule)

_______________________________________________________________

Actual Cost:

This gives the actual amount spent until that point of time. Eg in our case, what is the actual cost that is spent until 3rd week?

Formula: Effort per hours * Total number of hours.

Lets assume that in our example, for doing the 70% of the work the team had spent 30 hrs and each hr is charged at Rs 30.

Therefore Actual Cost in our case = 30 * 30 = Rs 900

_______________________________________________________________

Cost Variance:

Formula: EV - AC 

The cost variance gives us an idea of how much we have spent to get a specific value for that expenditure. In our example, we have spent Rs 900, but we have got the product output of worth Rs 700 only.

Hence, CV = 700 - 900 = Rs -200. This shows that we are Rs 200 behind the budget.

_______________________________________________________________

Cost Performance Index:

Formula = EV/AC 

In our example: CPI = 700/900 = ~ 0.8 (A value < 1, implies that we are over the budget!)

_______________________________________________________________

Estimation At Completion (EAC):

So far we have got an idea of how much value of product we have earned, the cost that we have paid and the planned value of product we should have earned. We also saw that in our example, we are over the budget, unfortunately. So if the project goes at this rate, what would the budget that would be required to bring it to completion? That is called EAC.

Formula: EAC = Budget / CPI

In our example: EAC = 1000/0.8 = Rs 1250. 

Hence by end of the project we would need Rs 250 extra. 

This gives an idea for the management to decide how much extra funding they need to arrange or assess how to reduce the overshoot etc. EAC becomes a very important metric to take decisions with respect to budget.

_______________________________________________________________

###############################################################

Context Switching

 One of the metrics that a Scrum Master need to look out for is the "Velocity" - where the metric should be calculated in terms of both story points as well as number of stories.

Why is that so? Isn't tracking velocity at story points not sufficient?

Let us take the below scenario:

Team A has the below velocity: Story points = 70 and # Stories = 9 

If they want to set the velocity for the upcoming sprint as 70 points and yet deliver it with a number of shorter stories (eg: 20 stories), is that fine?

Although this appears to be devoid of risks, the team should keep in mind, what is known as context switching. 

What is Context Switching:

It is the time lost (i.e) productivity loss when we switch over from Task 1 to Task 2 and back to Task 1. It is estimated to be 20%. So in order to resume Task 1, due to the switch over, there is a time loss to get back to its context.

There have been many studies in this area, and the out come strongly points to the fact that context switching increases wastage. Computer scientist 'George Weinburg' gathered data around this and published the below details.

As we can see, the more multitasking is involved, greater the context switching and the loss %. As a Scrum Master, it is therefore necessary to consider velocity at both # of Story Points and at # of Stories level.

################################################################

Key Quality Metrics

 In this blog we will discuss some of the key Quality Metrics.

Metric	Definition
Defect Leakage	It is the number of defects that is found by customers and NOT by the project team. Ideally it should be < 10%, however teams can strive for 5% or less as part of their optimizations.
Defect Injection Rate	The number of defects raised per day. If the trend is such that the number of defects identified are more at the beginning and it gradually reduces towards the end, it means that the project is in good health wrt quality.
Defect Density	The number of defects found in say a million lines of code Formula: Number of defects/LOC (in Million)
Code Coverage	The number of lines of code that the test case/suite covers as part of testing
Review Efficiency	The number of defects found during the review process. Either design review or code review etc Eg: Say, we need to find the review efficiency for detailed design document review: Formula = Number of defects found during DD review / (Number of defects found during DD review + Number of defects found in later stages of the project that has source as Detailed Design Phase) The above formula can also be extrapolated to Testing to obtain Test Efficiency. Eg: Test Efficiency for System Testing Phase = Number of Defects found in ST Phase / (Number of defects found in ST + SIT + UAT)
Defect Removal Efficiency	The number of defects resolved by the Dev team/Total number of defects raised.