Agile Abuse – Scenario 6 – Story point is not about time, not even a range
 

Sumant – Developer 1, Veena – Scrum Master

Veena – Sumant, we are almost at last day of sprint and your 3 pointers are not yet done. Do you see a risk? What is the tentative time you think you would take?

Sumant – I can’t tell you. Agile says that you cannot convert story points to time hence 3 pointers can take 3 days or 3 months. All valid in agile.

Veena – Why do you estimate your stories?

Sumant  – So that we know whether we can do that in our sprint or not.

Veena – And a sprint duration can be 3 months too?

Sumant – Oops, I got it.  My bad!

Challenge – The story point is not about time, not even a range.

 

Scenario 7 – We will unearth the acceptance criteria and requirements for a given story as we continue with development. Writing a one-liner description for a story should be fine and we will keep looking at it while working in progress during the sprint.

Agile Abuse – Scenario 5 – Let’s play with estimation whenever we want
 

Ron – Developer 1, Amy – Scrum Master

Amy – How come we committed 45 story points and we accomplished 51 though I have not added any extra work to sprint.

Ron – The performance improvement story was a little complicated hence I have added 6 additional points to it.

Amy – Once an estimate is done, it is not supposed to change in any case. If so, the whole point of estimation has no value.

Ron – Sorry, I will change that back to original and add the challenges encountered with that story to our process asset library.

Challenge – It is perfectly alright to play with estimation at any point in time.  

Scenario 6 – Story point is not about time, not even a range

Agile Abuse – Scenario 4 – Sprinting means running super fast
 

Paula – Customer, Amy – Manager

Paula – Amy, you mentioned that Agile is supposed to be faster. Why don’t you speed up the work with the same team? Sprint velocity is supposed to improve sprint after sprint and the speed of work should constantly increase.

Amy – Too much speed can affect the quality of work. Agile promotes sustainable development. In a long run, the overall benefit with respect to quality is going to be more compare to quantity in most circumstances while the sprint can run with a pace and all you can expect is better quality sprint after sprint.  100% utilization is an economic disaster.

Paula – OK. Got it.

Challenge – ‘Sprinting’ means running super-fast.

Scenario 5 – It is perfectly alright to play with estimation at any point in time.  

Agile Abuse – Scenario 3 – Converting standup to status meeting
 

Ron – Manager, Amy – Scrum Master

Ron – Amy, why the heck stand-ups are going for an hour every day.

Amy – The team prefers to talk and sort out open items. Although there is some unwanted discussions as well but that is just to keep morale up. It is truly helping us to sort out open items every day.

Ron – There is something wrong here. Are the questions being asked or clarification expected common to all?

Amy – Not really. Once in a while, it is general but typically it’s between two people.  It helps everyone to get the perspective.

Ron – You really need to take those discussions offline. The standup is supposed to end in less than 10 minutes (Worst case 15 minutes) for 10 member team.  You can do planning or grooming once or twice a week but that must have to be a separate meeting and not a standup.

Challenge – A standup cannot be a meeting.

Scenario 4 – ‘Sprinting’ means running super-fast.

Agile Abuse – Scenario 2 – Mixing Pairing and Knowledge Transition
 

Steve – Developer 1, Jeff – Developer 2

Steve (Evening) – Jeff, Can I pair with you on your story?

Jeff – Sure, but I am almost done with my story and moreover I would leave in another hour or so. If you are still interested, please join me.

Next-day – Morning standup

Steve – I worked on adding a comments field to our customer UI and further added that to the database.

Jeff – I paired with Steve. Status – Ditto!!!

Message – I didn’t do anything hence pairing was a saver although it was knowledge transition.

Scenario 3 – A standup cannot be a meeting.

Agile Abuse – Scenario 1 – The fun of committing less than what you can accomplish
 

Kent – Scrum Master, Chris – Sr. Developer

Kent – Why do you work less than half a day?

Chris – I finish all my sprint work, I don’t need to look at time!

Kent – (During Sprint Planning) – I think we can pick more work. Chris, you being a senior developer, what do you say?

Chris – This is all we have been completing consistently in the past. That’s all we can do in a given time hence we should not add more points.

Challenge – I leave very early because I finish my work and I pick very less because this is all I can do.

Scenario 2  – I didn’t do anything hence pairing was a saver although it was knowledge transition.

Abusing Agile – Part 1
 

Disclaimer – There is no intention to hurt anybody. The idea is to pass the learning and a MESSAGE. I have seen Agile getting abused and many times it is visible to the rest of the world except the one who is responsible for it. Click on each scenario to get more details.

Scenario 1 – I leave very early because I finish my work and I pick very less because this is all I can do

Scenario 2  – I didn’t do anything hence pairing was a saver although it was knowledge transition.

Scenario 3 – A standup cannot be a meeting

Scenario 4 – ‘Sprinting’ means running super-fast

Scenario 5 – It is perfectly alright to play with estimation at any point in time.  

Scenario 6 – Story point is not about time, not even a range

Scenario 7 – We will unearth the acceptance criteria and requirements for a given story as we continue with development. Writing a one-liner description for a story should be fine and we will keep looking at it while working in progress during the sprint.  

 

Understand themes, epics and user stories
 

Themes – A Theme is a group of EPICS that represents area of focus.  For instance “Product going online” or “moving to cloud” or  “launch in India”. Typically program managers assign financial value to themes to ensure objectives and strategic direction of an organization is aligned with program. These are typically at very broader level (Program or entire project level)

EPICs – An Epic is a large story that cannot be completed in a single sprint hence it is broken down in group of user stories. Hence it would make more sense to say that EPICs are collection of related user stories.  For instance you say that theme is “Going to cloud” and EPIC is “improve password page usability”. The user story could be “The validation messages should be very clear so that I should be able to correct it easily”

User Stories –  User stories is a description of a software feature from an end user perspective who desires the new capability.  Precisely it is simplified version of user or customer requirements.

Here is the template for user story

As a <type of user>, I want <some goal> so that <some reason>.

 

A good user story can convey a clear understanding to programmer about requirement. The characteristic of user stories are

Testable, Estimable, Small, Negotiable, Independent and Valuable.

A specific user story can belong to more than one theme, but certainly does not to multiple epics.