Thursday, July 09, 2020

Agile Asanas: Story Map Vs Product Backlog – The Differences



Recently, I wrote an article about Story Map in agile development. The article describes the story mapping technique in detail and you will know the followings:
  • Story Map Definition
  • Building Blocks in a Story Map
    • Personas
    • Backbone
    • Walking Skeleton
  • Release Planning with a Story Map
  • Story Map vs Product Backlog
  • A Practical Story Map (Hands-on Example)

You can read this article here:
The Big Picture with Story Map in Agile Development

 [ To read all posts in Agile Asanas series, use this link. ]
I’ve received emails on this article from founders of software organizations and CEOs, who have online tools for story maps, product backlog etc., available in their product portfolio. In addition, there are quite a few questions from Product Owners, Managers on why one should go for a Story Map instead of Product Backlog?

 To answer that, you need to know the differences between these two – story map and (product) backlog.

 Let’s check them one by one. 

 It’s not an exclusive list, there can be others as well, some of which I’ve noted in the conclusion part of this article. 
Difference - 1: Story Map gives the big picture of the product or solution that you are building, Product Backlog doesn’t. 

 The product backlog has all the items listed that you are to be delivered in a product – features, stories, bugs, fixes to be done, improvements etc. While working with this artifact, the team members don’t get the big picture – of what they are building in a sequence of steps. Usually the team members work on tasks (stories broken down to tasks) and hence, it’s not easy for them to see the big picture. 
Story map on the other hand helps everyone in the team and also the customer to see the big picture.

 As noted in the previous linked article, with a story map you don’t miss the forest for the trees. 
The big picture tells the story of the entire system/product/solution you and your team are building. 



Difference - 2: Story Map is a two-dimensional (2D) visual structure, where the product backlog is a one-dimensional (1D) non-visual one. 
Because the story map is a visual structure, everyone can see what is being worked-upon visually and how the system is built – just one single snapshot on the wall or electronic board.

 Also, because it’s visual it shows the workflow of the system and gives a context to the discussion while writing stories. After all, stories are primarily about communication.  

The backlog shown above is a graphical one for your understanding. In real-time, it will be a one-dimensional figure in an excel sheet or any software tool such as MS Project or Atlassian Jira or any other.
Difference - 3: Story Map on its own acts as product prioritization technique, whereas the Product Backlog does not.
There are quite a few product backlog prioritization techniques that a Product Manager or Product Owner can follow, while refining the backlog. Some of them are: simple schemes (e.g., high, medium, low), monopoly money, Kano method, MoSCoW method etc.

 You can read more on various product prioritization techniques here: 
Product Prioritization Techniques in Agile Development

 With a story map, as you are building your backbone or walking skeleton, you are actually tacitly prioritizing! Do remember that the backlog gives you the Minimum Viable Product (MVP) - the minimum set of capabilities needed to deliver the product or solution or service. Without prioritization, you just can’t have it. Can you?

 Similarly, as you build the skeleton part of the backlog, you are also having the Minimum Marketable Features (MMF) – the set of features that makes the product minimally functional. Again, here too, prioritization is involved. 

 Going further, as you – the product owner/manager, chalk out the release strategy with the project manager and team members, you will be again doing prioritization, i.e., which one will go into the first release, which will go into the next and so on. 
Difference - 4: With a Story Map, you can easily show the dependencies, whereas with Backlog, you can’t. 
As we just saw, the story map is a 2D one, whereas the product backlog is a flat one. How will you show dependencies in a flat structure? 

 Story map doesn’t have this limitation. In fact, you can directly draw the dependencies on the wall or board (electronic or not) where you are building the story map. This brings in a lot of discussion among the team members and stakeholders, which is one thing I really like. Story map being about shared communication and shared understanding helps the team in this aspect. 

 Dependencies are key in any project – ask any manager who has really worked in any project. Solving dependencies takes a lot of time for the project manager. With a story map, you are doing it in front of everyone and from the beginning.
Difference - 5: With a Story Map, you can determine which part is missing in the system, whereas it’s not the case with Product Backlog. 
The story is told by a stakeholder or use from left-to-right in a sequence of steps - each step being an activity (or epic). This sets the narrative flow. 

 Under each activity (or epic), we have a set of tasks (or stories) decomposed from the respective epic. These stories are placed vertically from top-to-bottom. 


Product Backlog is not represented in a sequence of steps and then each step broken down further vertically – because it’s flat structure. Hence, it won’t be easy to determine which one went missing from the customer’s perspective to build a system or solution.

 Difference - 6: Tracing and Monitoring of a story can happen with the Story Map, whereas with the Product Backlog you can’t do so easily. 
The backbone has the epics which are basically a sequence of steps. The backbone also can have a couple of levels of its own if the sequence of steps is too large in number. You can roll-up from the lower-level to the higher-level. 

 Below the backlog we have the walking skeleton, which describes each step in more detail, i.e., in the (user) story format.

 Hence, if you or your team member wants to trace or monitor a particular story (which is under an epic or feature), you can do so easily.
Difference - 7: If there are a large number of stories, then the Story Map can take a huge space, which is not usually the case with the Product Backlog.

Now, this one goes against the Story Map! If there are a very large number of stories, then the story map can be a very big space in your working area. Sometimes it can even run into multiple walls if you are using a physical space or can run into pages and pages if you are using an electronic tool.
I won’t say this constraint applies to the Product Backlog, though a backlog can also be very big in size. However, because it’s one-dimensional and flat, it won’t be as acute as the case for a very large story map.

 Conclusion
There are many other things one can derive when you compare the story map with the product backlog. For example, with a story map, you can decide which one needs more or less analysis as you proceed with your development and this can be done in a visual way. I’ve also noticed a drawback with story maps, i.e., a large story map can take much space. 

 Another thing I’ve noticed is that many product managers or owners don’t understand the concept of story maps properly and mess it up. 

So, first understand the concept of story map well. Also, do note that it can have variations. For product managers, the ONLY way to understand is to do it yourself and take feedback from your team members. Then decide which one to go for – Story Map or Product Backlog or a combination of both (which I’ve noted also in the linked first article). 
References:
[2] Article: The Big Picture with Story Map in Agile Development, first published by Microsoft Project User Group, written by Satya Narayan Dash
[3] User Story Mapping – Discover the Whole Story, Build the Right Product, by Jeff Patton with Peter Economy



Posted by at No comments:
Labels: , , ,

Wednesday, July 01, 2020

Book Review - I Want to Be An ACP: Important Not Only for The Exam, But Also A Treasure of Knowledge To Apply in The Real-World

By Suresh Juturu, PMP, ACP, CSM
The book written by Satya Narayan Dash – I Want To Be An ACP, the plain and simple way to be a PMI-ACP - is particularly written for candidates aspiring to clear the Agile Certified Practitioner (ACP®) examination. This certification examination is from Project Management Institute (PMI®).  

Chapters Covered

The book covers all the important topics of Agile in nine chapters. 
The chapters covered are:
  • Welcome and Introduction, which covers the fundamentals on how to read the book and take the ACP exam. 
  • The next seven chapters covers the seven domains of PMI-ACP exam, i.e., Agile Principles and Mindset, Value Driven Delivery, Stakeholder Engagement, Team Performance, Adaptive Planning, Problem Detection and Resolution, and Continuous Improvement.
  • The final chapter covers a presentation on how to be a PMI-ACP.

 You can know more on the chapters from the book index:

Key Areas
This book gives immense knowledge on these agile topics:

  • What is Agile: It covers all basics on agile framework.
  • How Agile works: All types of agile approaches such as Scrum, Kanban, Lean, XP, BDD, TDD etc. are covered.
  • How Agile teams are to be managed: You will learn various conflict management techniques for your agile team. You will learn how to do performance management for your team.
  • When to use Agile: You will learn when and how to choose the right agile approach. 
  • Where and how to focus when Agile deployment is not going well: For example, you will learn a number of innovation games.

Another aspect of the book is extensive coverage of Agile Earned Value Management (AgileEVM). It’s not an easy concept to grasp. But dedicated videos for this section covers the concepts of EVM, along with all the needed formulae.

 In particular, I'll mention the Chapter 6: Adaptive Planning, where it is illustrated with various techniques on how to do cost baseline for agile projects and how different when compared with the normal waterfall projects. It also provides the extensive details on deltas of EVMs while following agile vs waterfall.
Conclusion
Most importantly, I would like to mention that the book reading is important not only for passing the exam, it is a great treasure for revising the knowledge on the agile concepts while you deploy these practices over time in the real world.


Brief Profile:
Suresh Juturu, PMP, ACP, CSM, CMMI V2 Associate
https://www.linkedin.com/in/suresh-juturu-pmp®-acp®-csm®

Book Available for ACP Exam Prep:

Book Excerpts:

PMI-ACP Success Stories:


Posted by at No comments:
Labels: , , , , , , , ,

Friday, June 19, 2020

Agile Asanas: Bus Factor, Broken-Comb Skills and Cross-Functional Teams



Imagine this situation. You are managing a critical project for organization and the constraints for the project are quite tight. During execution, one of the key team members left the project. This team member was working on a very important component! 
  • If you have managed many projects over years, you would have faced such a situation. Do you remember the feeling?
  • Do you remember how frantic the next few days were?

Resource churn is very likely to happen in projects. New people will join the project, existing people will leave or may be transferred to another project. 

People may suddenly fall sick, may take forced leave due personal emergencies or team members may be reduced due to cost related measures or other constraints. These things - some or all - will happen. You can never stop it.

[ To read all posts in Agile Asanas series, use this link. ]



But then, how do you manage such situations?  

This leads us to a concept called bus factor. Let's understand this concept first.
Bus Factor

 The bus factor is a numeric number. This number equals the number of team members, who if were to be hit by a bus and hence, will put the project in a serious situation. 

 Simplifying, you can say it’s the number of people in a project team who have to be hit by a bus before the project is in a dire situation. 

 Let’s say your bus factor is numeric “1”.  It means if just one team member is hit by a bus (just a way of saying, not actually being hit by a bus!), then the project is in trouble. If just one of your team members leaves the project or transfers or takes off, your project will come to a stand-still. 

 In other words, with a low bus factor, your project is not really protected. On the other hand, with a high bus factor your project is relatively better. Because with a higher bus factor, your project can survive in spite of multiple team members leaving (or the proverbial being hit by the bus). 

 Hence, you can say:
The higher the bus factor for a project, the better.The ideal bus factor equals the number of members in the project team.

 There are other names for bus factor, such as lorry factor, truck factor, etc. However, the concept remains the same.

 A team with a bus factor of value “5” is better than a team with a bus factor of value “2”. The bus factor cannot be negative. Hence, for your project, you should try to have a high bus factor. 

 Related to bus factor, we have another concept called broken-comb skills. With such skilled team members, you can have a high bus factor.
Broken-Comb Skills

 The team members in an Agile project should be Generalizing-Specialists, i.e., specialists in a particular skill, but have other skills as well, possibly to a lesser extent.

 Team members tend to be highly specialized in waterfall organization, but in agile development, the team size is kept to be reasonable – sometimes just three people. Because of a small team size, you need to have "generalizing specialists". The concept of generalizing specialist translates to a skillset known as T-shaped skills.

 Team members should be encouraged to build a T-shaped skill. The vertical side of T (one of the alphabets) represents specialization. The horizontal side of T represents generalization, i.e., have also other skills spread across other areas.

 Developers should be encouraged to test, testers should be encouraged to do release activities; however, the specialization for an individual team member is there.

 Agile teams should have members with T-shaped skills, rather than I-shaped skills. People with I-shaped skills have deep specialization in one domain, but lack expertise (or interest) in other domains. This is represented in the figure below.
Image Source: Book - I Want To Be An ACP, 2nd Edition

As shown, T-shaped people have deeper understanding in one area or specialists in one area, but have less experience in many others. However, this may not be sufficient in small teams with rapid changes. Hence, in such cases, we need broken-comb skills. With broken-comb skilled people, you have deeper experiences across various disciplines, not just one discipline. In other words, broken-comb people will have various specialization areas, not just one specialization area. This is shown below.
Image Source: Book - I Want To Be An ACP, 2nd Edition

Because they have a large range of skills, you can use them effectively and efficiently compared to T-shaped skills who have very low skill in the generalization area. The other name of it is paint-drip skills.


 Cross-Functional Teams
If you have worked in Agile projects, you would be knowing that the team is strongly encouraged to be cross-functional. 

 A cross-functional team means that the Team has all the skills needed to get the work done. A cross-functional team means that the development team is no longer made up solely of programmers.

 The agile development team consists of all the key players needed to create an increment of working code: coders, testers, analysts, architects, technical writers, and so on. It doesn’t mean that everyone in the team has all the needed skills, but the team - collectively - has the needed skills to get the work done. 

 A team member is brought in with a particular skill set. But as the team matures, each one learns more about other tasks and responsibilities. It is possible that the team, initially, may not expertise in some areas and in such cases, but over time, the team should strive to be generalizing specialists. 


 Bringing All Three Together
In fact, to be a good cross-functional team as noted before, the team must consist of people who are generalizing specialists. 

 The broken-comb or paint-drip skills add-up to be a better cross-functional team. Because with these skills, the team members are not specialists in one area and generalists in another, but the team members have specializations in multiple areas. 

 So, what does it have to do with the Bus Factor that we understood earlier?

 Imagine having a cross-functional team with generalizing specialists and broken-comb skills. What will be the bus factor for this team?

 If not the ideal value, it will be close to that. Of course, when a team member working on a critical component leaves, there will be some impact, but the feeling won’t be like that of “being hit by a bus” and frantically trying to recover. The team and project will recover very quickly. 

 In fact, I would conclude by saying: 
A cross-functional team with team members having paint-drip or broken-comb skills will have high team resiliency and also high project resiliency. This is because the bus factor is near perfect for the team.
References:

 [1] Book: I Want To Be A PMI-ACP: The Plain and Simple Way, 2nd Edition, by Satya Narayan Dash

 [2] Agile Practice Guide, by Project Management Institute (PMI)

Agile Asanas Series:




Posted by at No comments:
Labels: , ,

Tuesday, June 09, 2020

RMP Success Story: Risk Management - Essential for Professional and Personal Success

By John P S Oliver, RMP, PBA, PMP

Introduction
Being a Supply Chain Management professional handling various stakeholders in a highly regulated industry with strict compliance rules and involved in process improvement projects, risk management is one of the core areas of focus for my function and managing risks is one of the key objectives for my role. 

 While I gained knowledge on Risk Management processes as part of my preparation for PMP certification, I wanted to further improve my knowledge of Risk Management and decided to go for the PMI-RMP® certification.

 My earlier PMP exam experience: 
PMP Live Lessons Was Instrumental in Getting My PMP Credential


 Own Study
Once I decided to take the PMI-RMP certification, I scouted for the PMI-RMP training class that would provide me with the mandatory 30 hours of risk management education.
I reached out to Satya Sir since he was my coach for the PMP certification. However, I found out that he was not conducting any class room training session for RMP in the near future. I also came to know that he had just published the second edition of his book - I Want To Be A RMP targeting aspirants for PMI-RMP exam. I then enrolled for the PMI-RMP online training session with a provider, completed it and earned the mandatory 30 PDUs. I then submitted my PMI-RMP application on 21-Oct-2019 and it was accepted by PMI on 28-Oct-2019.

 Once my application was accepted, I bought Satya Sir’s Book I Want To Be A RMP, 2nd Edition. I also referenced 3 other books from PMI®, Practice Standard for Project Risk Management, The Standard for Risk Management in Portfolios, Programs and Projects and PMBOK® Guide – 6th Edition.

 I began my preparation for the exam in the 1st week of February and completed reading Satya Sir’s Book fully once, taking up the chapter end questions as soon as I completed each chapter. I then referenced the 3 books from PMI mentioned above.

 I then took up the two full question sets from Satya Sir’s RMP book. This gave me a good perspective of the areas for improvement. Next, I started my revision of Satya Sir’s Book.

 Once I completed the revision, I again attempted all the chapter end questions as well as the two full set questions. I could see a marked improvement in my scores over my previous score. I also attempted Udemy’s simulation questions for PMI-RMP to improve my knowledge.

 RMP Exam Experience
After the revision of Satya Sir’s Book, I scheduled my PMI-RMP exam for 23-Mar-2020 at the Pearson Professional Center at Chennai. However, my exam was cancelled by Pearson Vue due to the COVID-19 lockdown and I was asked to reschedule the exam to a later date.

 I then rescheduled my exam multiple times for 7-Apr-2020, 8-May-2020, 11-May-2020, 18-May-2020, 27-May-2020 however the exams for these dates were cancelled by Pearson Vue due to the extension of COVID-19 lockdown in Chennai. Finally, I rescheduled the exam for 5-Jun-2020 at 9:00 AM, since Pearson Vue center at Chennai started functioning again from 03-Jun-2020.

 I reached Pearson Vue Center by 7:45 AM on 05-Jun-2020 and completed my formalities including the screening and declaration procedures with regards to COVID-19 precautions. Due to COVID-19 precautions, I had to wear mask and gloves for the entire duration of the exam.

 I was allowed to start my exam by 8:15 AM and completed the exam in one go without any breaks with 12 minutes of spare time. I reviewed 6 questions that I had marked for review.

 Questions Faced:
  • Most of the questions were situational.
  • There were few mathematical questions such as Monte Carlo Analysis, Sensitivity Analysis. 
  • I’ve also received questions on Contingency Reserve and Expected Monetary Value (EMV).
  • There were questions on Latin Hypercube Simulation (LHS). 

 Book Review - I Want To Be A RMP, 2nd Edition
As soon as I decided to go for the PMI-RMP certification, I reached out to Satya Sir since he was my coach for the PMP certification. It was at the same time that he had released the 2nd edition of his popular book: I Want To Be A RMP. 

 I had already known about his popular book for PMP aspirants, I Want To Be A PMP and had used his PMP Live Lessons which was in videos. Hence it was a no brainer and I decided to buy his book for RMP preparation.

 The book is organized by chapters and it is easy to follow. In addition to ITTOs and the explanation of why it is an ITTO for the particular process, it has additional yogic vision and revision tips which make sure we do not miss the key concepts.

 The fascinating aspect of the book is that Satya Sir uses real life situations and examples to drive home the risk management concepts. This helps us to easily understand and remember the concepts.

 The book has a separate chapter for mathematical questions along with flash card for mathematical formulas. This helped in my preparation for the mathematical questions which are easy to score.

 The book also covers Sensitivity Analysis, Decision Tree analysis, Contingency reserves, Simulations like Monte Carlo, LHS along with examples which is very important from the exam point of view.
Suggestions for RMP Aspirants
Dos:
  • Plan and schedule your exam well in advance.
  • Prepare a realistic study schedule and follow it rigorously.
  • In addition to PMI reference books, go for another study resource like “I Want To Be A RMP” or other published books to aid you in your studies. 
  • Review your answers both the right and the wrong ones to understand the reasoning and logic behind the answers. This will help you to get familiarized with the pattern behind the questions and answers.
  • Spend at least 30% of your overall schedule to attempt practice questions.
Don’ts:
  • Do not attempt questions before you completely study the resources at least once.
  • Do not use more than 2 or 3 study resources (PMI reference books + 1) – That may end up confusing you as well as take your time which can be spent on practicing Questions & Answers.
  • Don’t panic during the exam if you do not know the answer for a particular question - mark it for review and go the next one – You can always come back to the marked question later.

 Conclusion
I would like to thank the Almighty for his blessings, my reporting manager for his approval to take up this certification and Satya Sir for his book: I Want To Be A RMP. I am confident that with the knowledge gained, I would be able to apply the concept of risk management more effectively in my day to day operations and projects.

Brief Profile: 
Name: John P S Oliver
Current Role: Supply Chain Manager
Experience: 22+ years of experience in Operations, Vendor Management and Project Management in ITES across SCM, Healthcare, Banking and Financial services, Telecom and Retail verticals.



New Book Available for RMP Exam:
You may also like:
Posted by at No comments:
Labels: , , , , ,
Subscribe to: Posts (Atom)