Thursday, August 7, 2014

Dollar value of a story $$$

“As a network administrator, i want the ability to update the timeout value in application configurations remotely through a management portal”

 

If this is a SaaS deployment and you feel that it has a good value add for the admin consumer, it looks like a good story. But if you have one enterprise application and you want to help your network admin by building this feature it might not be a good value for money.

 

How do you explain this to developer, without a closed door meeting?

If you are following agile, work as a team. Don't hide facts and numbers. One simple number that your team should be knowing is the cost of running one sprint. When i say cost, it the cost to company to manage X team members for Y days. Say your cost per sprint is $30K and your velocity is 30 points, it will be roughly 1000$ for a story point ( you may as well argue that it will not be so proportional, neither the story  points.)

 

Now look back at the story point one would give for the story mentioned, if team decides as 5 points -  its good 5K. Now decide, will you educate the system admin to do this manually or go back and write an application to do it for 5K?

 

Once the team understand the cost aspect, you don't really have to  explain about the ‘cost of poor quality’ to team.

Agile and Developer

If you are a developer working in an organization where everyone is talking about agile and only your project manager seems to be excited about it. Here are the things you need to do as a developer.

Before you go any further about TDD, BDD and all test driven approach, take a moment and think about what you could do adopt right away if your manager is talking about agile. No doubt that you need to write Unit tests, TDDs but before we need to understand what it is.

Agile manifesto says

“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”

Now from developer’s perspective lets look at the highlighted lines.

“Working Software over…”, says that you starts showing the working software and demo it often. But this requires that you to build something that can be demoed, not shown as a presentation or as a code. You could do this only if you have very small requirement and they are independent

Now, first part is easy. Product owner can breakdown the features. But second part is tougher one. This is where you need to pitch in. But verifying if the feature can be implemented with writing the code required only for this feature is your job. This is when you break down the story and suggest PO.

Lets take an example, where you need to show a webpage where based on the role you need to implement a feature say an admin action. If you have to implement this feature end to end you need following features ready

  1. Login implemented
  2. Role assignment implemented
  3. Role to feature mapping done
  4. New feature itself

say you implement this in the same order and say you take a sprint to implement each, then every demo what you are showing is what stake holder has seen elsewhere. Something like role and feature mapping might not even go beyond the code and unit test.

 

So what did stake holder get in first 3 sprints?

Close to nothing.

 

Now what if you implement the new feature(say showing some grid with all data) without any security implementation. During the demo you can show, how will data look. Is this the right presentation, can we do anything better and you are giving good time for your stake holders to sleep over it and come back with all possible related stories. Now during next demo, you show login and apply the effect of authentication to the feature built. 

 

Did we turn the world upside down in the name of Agile? But did we get right feedback and testing done soon? That’s the beginning!