Probabilistic project sizing using Randomized Branch Sampling (RBS)

Editor's Notes

• #8: It means that to plan initiatives, features or epics you have to break them down to user stories. It requires quite significant analysis process and it can easily happen that great part of this effort will be a pure waste. Priorities of initiatives and features can change and feature will not be started at all. This practice is hard to follow.
• #10: http://senate.universityofcalifornia.edu/inmemoriam/RaymondJessen.htm Randomized branch sampling (RBS) was first proposed by Jessen (Jessen, 1955). It is a multi-stage unequal probability sampling method. The technique was designed to efficiently estimate the total number of fruit (oranges) found in the canopy of a tree while only having to count the fruit on select branches. RBS is a method for sampling tree branches which does not require prior identification of all branches, and provides the sampler with unbiased tree level estimates. As an example, we suppose that it is of interest to estimate the total number of fruit on a apple tree. The number of fruit on the tree is the population and it is desired to select a sample from which an estimate of the population's number can be obtained. In the case of the apple tree, the samples to be selected are the terminal branches upon which the fruit is typically borne.
• #11: RBS is a method for sampling tree branches which does not require prior identification of all branches, and provides the sampler with unbiased tree level estimates. With RBS, branches are selected from the tree by creating a pathway which starts at the base of the bole and travels upwards. Every time the path encounters a fork (branching), selection probabilities are calculated proportional to the size of each limb emanating from the fork. A random number is then generated to determine the limb through which the path continues to travel along. This procedure is repeated up the tree until the path selects a terminal branch which is small enough that it becomes easy to measure the number of fruit. A tree level estimate is derived by combining the number of fruit from the terminal branch and the associated probability with which that particular branch was selected. RBS is an advantageous sampling scheme in the field because it does not require the user to take measurements on, or to have prior knowledge of all branches in the crown.
• #12: Epics are the highest-level requirements artifact. Epics are not implemented directly but are broken into user stories, which are the primitives used by the teams for actual coding and testing. ‹‹ Epics are not directly testable. Instead, they are tested by the acceptance tests associated with the user stories that implement them. When breaking an epic down do not consider how many steps the workflow will consist of. Consider the user story the only work item type at the lowest level of granularity.
• #16: The assumption behind using RBS for software development is that project size depends on the context – the customer, the people developing the product and the methodology they use for managing the requirements, breaking down the product into stories and sizing a story. It doesn’t matter what the methodology is – Planning Poker (Cohn, 2005), Product Sashimi (Rainsberger, 2012), Behavior Driven Development (North, 2006), Feature Driven Development (Coad, 1999) etc. What is important is the methodology to be cohesive, explicit and to be consistently applied during project execution when we slice the requirements into user stories. RBS estimates the original scope. Then there is a relationship between the original and eventual (emergent, expanded) scope which we only identify when the results of the execution of our plans meet the customer). The scope expansion occurs when the requirement change risk materializes.
• #17: I teamed up with Ajay Reddy and the CodeGenesys/ScrumDo.com team to test the correlation between project sizes estimated using RBS and the actual story points estimated in thirteen randomly selected projects from the pool of real Scrumdo projects that met the following criteria: Epic-Story-Task breakdowns Successful release history Stable teams (systems) Have an active ScrumDo coach or scrum master Commercial projects Have a minimum size of 12 epics/features. As seen on the scatterplot below we found a very strong correlation between project sizes estimated using RBS and the actual number of stories estimated for some real Scrumdo projects.
• #26: Mapping Product = Trunk Epic = Branch User Story = Terminal Shoot
• #35: “Randomly sample at least 7 and ideally 11 of the customer defined requirements and analyze them into work items that are meaningful to the development organization. User stories is just one example of a suitable work item type.” “Take the average number of the user stories per saga and multiply it with the number of sagas. The product is the number of user stories for the project.” “replace "user stories" with "work items suitable for the development organization."” http://www.lean-kanban-conference.de/what-happened-2011/predictability-and-measurement-with-kanban/ https://groups.yahoo.com/neo/groups/kanbandev/conversations/messages/16704
• #37: Epics are the highest-level requirements artifact. Epics are not implemented directly but are broken into user stories, which are the primitives used by the teams for actual coding and testing. ‹‹ Epics are not directly testable. Instead, they are tested by the acceptance tests associated with the user stories that implement them. When breaking an epic down do not consider how many steps the workflow will consist of. Consider the user story the only work item type at the lowest level of granularity.
• #39: Product = Trunk Epic = Branch User Story = Terminal Shoot Story points = Number of Fruit on the shoot
• #48: The delivery time per scenario will come from the historical delivery rate of the system.
• #50: Mapping Product = Trunk Epic = Branch User Story = Terminal Shoot Number of tasks per User story = Number of Fruit on the Shoot
• #58: The delivery time per scenario will come from the historical delivery rate of the system.
• #62: Mapping Product = Trunk Epic = Branch User Story = Terminal Shoot Number of Scenarios per User story = Number of Fruit on the Shoot
• #67: Thank you very much for your attention. My hope is that you will start using this approach for high-level planning your next project. Dimitar Bakardzhiev is the Managing Director of Taller Technologies Bulgaria and an expert in driving successful and cost-effective technology development. As a Lean-Kanban University (LKU)-Accredited Kanban Trainer (AKT) and avid, expert Kanban practitioner, Dimitar puts lean principles to work every day when managing complex software projects with a special focus on building innovative, powerful mobile CRM solutions. Dimitar has been one of the leading proponents and evangelists of Kanban in his native Bulgaria and has published David Anderson’s Kanban book as well as books by Eli Goldratt and W. Edwards Deming in the local language. He is also a lecturer and frequent speaker at numerous conferences and his passion is to educate audiences on the benefits of lean principles and agile methodologies for software development.