Special Offers on Trainings

This blog has a tie up with Many top online training providers who are offering great deals for readers of this blog. The certifications covered include PMP, PMI RMP, PMI ACP, CAPM, Scrum Master Certification etc.

Click here to check them out.

Wednesday, March 1, 2017

Do We Need a Complicated Story Hierarchy?

One of the vital parts of any Agile or Scrum project is the User Story. A user story represents a piece of product functionality that needs to be built by the team. There was an article a few weeks back about “How to Write a Good User Story”. One of the questions new scrum teams have is about the relationship stories are supposed to have. In an ideal world every user story is independent but in the real world that's rarely the case. The purpose of this article is to help you understand if you need a complicated Story Hierarchy for your backlog.

Story Hierarchy? What do I mean by that?


Let me give you an example. Let us say you are building an online banking product. This product would have many major functionalities like login, view statements & balances, fund transfers, pay bills and so on. If you right a single user story for something like Fund Transfers, your story is going to humongous and not to mention take multiple iterations to finish. So, you would probably split Fund Transfers into multiple smaller parts like – Transfer to own accounts, Transfer to 3rd parties within the bank, Transfer to external parties. Now, transfer to external parties isn’t a small story either. You might have multiple fund transfer options like for ex: India has 2 inter-bank fund transfer options – NEFT and RTGS. So, you may break down the transfer to external parties into transfer by NEFT and transfer by RTGS.

Get the picture?

This is what I mean by Story Hierarchy.

Do We Need a Complicated Story Hierarchy?


Complicated Story Hierarchy – No.
Story Hierarchy – Yes.

You may be confused by my answer above. I have said Yes for having a Story Hierarchy but have said No for a Complicated Hierarchy. What exactly do I mean?

I mean that, firstly we shouldn't have too many levels in the story hierarchy because too many levels introduces unwanted complexity. Secondly, we should do-away with complex names for the different levels. In one of my neighboring scrum projects, they had so many different levels like – Feature à Super Epic à Epic à Headline à Story à Child Story and so on. Much of the teams time and effort goes into segregating user stories into one of these named categories and trying to cross-reference what comes from where.

If you ask me, I would prefer if we have at most 3 levels: Feature -> Epic -> User Story. The product backlog could consist of multiple Features. Each Feature could have multiple Epics and each Epic could be split into one or more User Stories. This keeps things simple and much more manageable. Doesn't it?

Does Having a Story Hierarchy have any Benefits?


Of course it does. Otherwise, why would I say Yes in the first place?

Remember the article on Lead Product Owner and hierarchical ownership of a Product? Categorizing Stories into hierarchy kind of gives us more flexibility in terms of tracking progress. Both Scrum Master and Product Owner can find out the % completion of the teams backlog on not just an overall level but also at a Feature or Epic level.

Team could target one Epic or one Feature at a time and finish them instead of working on user stories spanning across multiple different Epics or Features.
Not to mention, stories being finished in a single iteration instead of carrying over for 3 or 4.


What is your experience with Story Hierarchies? Do share them in the comments section.

No comments:

Post a Comment

Sample PMP Exam Q & A

If you are preparing for the PMP Exam and want to get your hands on hundreds of sample questions, reach me at anandvijayakumar007@gmail.com to find out more...

Google+ Badge

© 2013 by www.getpmpcertified.blogspot.com. All rights reserved. No part of this blog or its contents may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the Author.

Followers