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.

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