top
Sort by :

How To Generate Requirements From Use Cases

In earlier posts, I wrote about user stories that can help capture user’s requirements holistically and encompass the needs of your customers; I also wrote that user stories should then lead to use cases enabling your engineering team to get something concrete on paper for building. This is the third and final post in this series: How to generate requirements from use cases. The simplicity of this task can be misleading. If we, as project managers or product managers, fail to accurately translate our refined and well understood user stories, use cases into requirements; then our engineering team is doomed for failure. Why? Because requirements that were being tracked to completion before shipping were not completely and correctly comprehended, in spite of having good user stories and use cases. Hence, it is very simple but an important step where you should get final requirements correct down to the last detail. I could have used the term “write” or “create” requirements from use cases; like I did for my post of Use cases but I chose to use the term “generate”. Why?  Because your product or feature requirements should organically arise out of use cases and you only need to start the documentation process to have them recorded; assuming you have done your job correctly. Before proceeding, I humbly request you to please read and understand earlier two posts on “how to work with user stories” and “Use Cases - How they are different from user stories and how to create them”. And feel free to raise questions to me by replying to the comments or emailing me directly. Now, assuming that you have read those two articles; let us begin on the last stretch of this journey. What are requirements? Please take 30 seconds and try to put in words; what is meant by the term “requirements”? Time yourself! I am waiting. Tough! Isn’t it? Exactly! Because while we all intrinsically know what requirements mean, we are not able to put them into words and whatever can’t be put into words, can’t be explained to the audience. Unless we have a way to put our requirements into words exactly the way we understand them intrinsically, we will not succeed in our goals. To begin with, I define requirements as a clear concise sentence of not more than 10 words specifying the most singular unit of demand. A simple example of generating requirements from use cases: Let’s continue with the same toothpaste development example from my use cases post so that we all are on same page and mutual mental understanding remains. There we had developed a user story for John, our user, who wanted to feel fresh and energized even after 12-14 Hrs. of work day. And based on that, we had developed some use cases; remember? See the post here. Listing some use cases again here for ease. Use case 1: User wants to have a premium quality feel when he/she takes the toothpaste tube in hand before brushing. Use case 2: User gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube. Use case 3: User is able to notice the right amount of paste coming out of the tube every time, he/she brushes. It is never too much nor too little. One gentle squeeze always gives out the right amount of paste required for brushing. Now let us generate requirements out of those. Always remember, following things while generating requirements: Requirements should be concise and should contain only one demand in them. A single use case should not be giving rise to more than 2, at max 3, requirements. If a use case is able to generate more than 3 requirements then it is a clear sign that this use case is in fact a half-baked user story and needs to be broken down further. If a requirement cannot be expressed in less than 10 words then it is a use case in disguise and you need to relook at your user stories once again All requirements should have priority. We will be using tabular format so that we can maintain requirement traceability. 1) Requirement number has to be unique and will be used to track the requirement in various forums, discussions and work breakdown structures. Recommended format for requirement number is X.Y where X refers to the use case number and Y refers to the unique requirement within that use case. For example: 1.1, 1.2, 1.3 and so on to depict 1, 2, 3 requirements for use case 1. 2) Requirement description as we know is a clear concise sentence of less than 10 words depicting a single unit of demand 3) Use case generated from allows the product manager and engineering team to know which use case generated this particular requirement and suppose, down the line if use case or user story undergoes modification then we will clearly know which requirements are impacted and require a review. So it helps in that sense. 4) Business priority is not to be confused with task priority. Every task that is a child of a requirement will have its’ priority depicting the order in which they should be done. So, let us generate requirements for Use Case 1: “User wants to have a premium quality feel when he/she takes the toothpaste tube in their hand before brushing.” Now, let us generate requirements for Use Case 2: User gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube. Now, let us generate requirements for Use case 3: User is able to notice the right amount of paste coming out of the tube every time, he/she brushes. It is never too much nor too little. One gentle squeeze always gives out the right amount of paste required for brushing. And so on you can develop your requirements. I hope you enjoyed this post as much as I did! ☺ All the best!  
How To Generate Requirements From Use Cases
Abhinav
Abhinav

Abhinav Gupta

Blog Author

PMP, has 12+ years of experience working in Information technology sector and has worked with companies like Infosys and Microsoft in various capacities. He started his career as a manual tester for a world renowned software product and grew on to become automation champion in both functional as well as UI. He has worked with Healthcare units providing various software solutions to companies in North America and has worked with search engine based groups to enhance their experience and provide more bang for buck to their customers.

How To Generate Requirements From Use Cases

In earlier posts, I wrote about user stories that can help capture user’s requirements holistically and encompass the needs of your customers; I also wrote that user stories should then lead to use cases enabling your engineering team to get something concrete on paper for building. This is the third and final post in this series: How to generate requirements from use cases. The simplicity of this task can be misleading. If we, as project managers or product managers, fail to accurately translate our refined and well understood user stories, use cases into requirements; then our engineering team is doomed for failure. Why? Because requirements that were being tracked to completion before shipping were not completely and correctly comprehended, in spite of having good user stories and use cases. Hence, it is very simple but an important step where you should get final requirements correct down to the last detail. I could have used the term “write” or “create” requirements from use cases; like I did for my post of Use cases but I chose to use the term “generate”. Why?  Because your product or feature requirements should organically arise out of use cases and you only need to start the documentation process to have them recorded; assuming you have done your job correctly. Before proceeding, I humbly request you to please read and understand earlier two posts on “how to work with user stories” and “Use Cases - How they are different from user stories and how to create them”. And feel free to raise questions to me by replying to the comments or emailing me directly. Now, assuming that you have read those two articles; let us begin on the last stretch of this journey. What are requirements? Please take 30 seconds and try to put in words; what is meant by the term “requirements”? Time yourself! I am waiting. Tough! Isn’t it? Exactly! Because while we all intrinsically know what requirements mean, we are not able to put them into words and whatever can’t be put into words, can’t be explained to the audience. Unless we have a way to put our requirements into words exactly the way we understand them intrinsically, we will not succeed in our goals. To begin with, I define requirements as a clear concise sentence of not more than 10 words specifying the most singular unit of demand. A simple example of generating requirements from use cases: Let’s continue with the same toothpaste development example from my use cases post so that we all are on same page and mutual mental understanding remains. There we had developed a user story for John, our user, who wanted to feel fresh and energized even after 12-14 Hrs. of work day. And based on that, we had developed some use cases; remember? See the post here. Listing some use cases again here for ease. Use case 1: User wants to have a premium quality feel when he/she takes the toothpaste tube in hand before brushing. Use case 2: User gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube. Use case 3: User is able to notice the right amount of paste coming out of the tube every time, he/she brushes. It is never too much nor too little. One gentle squeeze always gives out the right amount of paste required for brushing. Now let us generate requirements out of those. Always remember, following things while generating requirements: Requirements should be concise and should contain only one demand in them. A single use case should not be giving rise to more than 2, at max 3, requirements. If a use case is able to generate more than 3 requirements then it is a clear sign that this use case is in fact a half-baked user story and needs to be broken down further. If a requirement cannot be expressed in less than 10 words then it is a use case in disguise and you need to relook at your user stories once again All requirements should have priority. We will be using tabular format so that we can maintain requirement traceability. 1) Requirement number has to be unique and will be used to track the requirement in various forums, discussions and work breakdown structures. Recommended format for requirement number is X.Y where X refers to the use case number and Y refers to the unique requirement within that use case. For example: 1.1, 1.2, 1.3 and so on to depict 1, 2, 3 requirements for use case 1. 2) Requirement description as we know is a clear concise sentence of less than 10 words depicting a single unit of demand 3) Use case generated from allows the product manager and engineering team to know which use case generated this particular requirement and suppose, down the line if use case or user story undergoes modification then we will clearly know which requirements are impacted and require a review. So it helps in that sense. 4) Business priority is not to be confused with task priority. Every task that is a child of a requirement will have its’ priority depicting the order in which they should be done. So, let us generate requirements for Use Case 1: “User wants to have a premium quality feel when he/she takes the toothpaste tube in their hand before brushing.” Now, let us generate requirements for Use Case 2: User gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube. Now, let us generate requirements for Use case 3: User is able to notice the right amount of paste coming out of the tube every time, he/she brushes. It is never too much nor too little. One gentle squeeze always gives out the right amount of paste required for brushing. And so on you can develop your requirements. I hope you enjoyed this post as much as I did! ☺ All the best!  
How To Generate Requirements From Use Cases
Author Image
How To Generate Requirements From Use Cases

How To Generate Requirements From Use Cases

Abhinav Gupta
In earlier posts, I wrote about user stories that can help capture user’s requirements holistically and encompass the needs of your customers; I also wrote that user stories should then lead to ...
Continue reading

ITIL Practitioner: Importance of “Adopt and Adapt” Principle and SWOT analysis

In my previous posts on ITIL Practitioner, we walked the journey of basics of ITIL practitioner, then emboldened by our little endeavor, we explored core competencies of ITIL, 9 guiding principles and tried to understand why “service strategy” is the core of ITIL framework. Briefly, we had touched upon the concept of Adopt and Adapt that is the core message of ITIL framework governing body. In this post, I will share my thoughts with you on how ITIL’s core concept of “Adopt and Adapt” is part of their curriculum and if possible, I will share some examples with you. What is Adopt and Adapt concept? Adopt says take whatever you like and think will be useful for your project or organization. Adapt says change it to suit your needs. Simple! Not so. Because this simple looking definition is full of pitfalls and very dangerous ones, at that. If you start adopting everything that you liked in other projects and companies then soon your own project and company will be overburdened with things that do not work well together and worst still, there will be humongous redundancy in techniques and tasks. Let us take a simple example of internet search engine. Suppose I am the owner of company XYZ and I am marketing a new internet search engine service known as XYZ-Search. While my engineers and managers are working hard to make sure that my internet search service performs well on the parameters that have been given to them; at the same time, I should also be spending time to find out the existing best practices being followed by my competitors and peers. But I exercise extreme restraint before actually taking those practices and asking my engineers to follow them blindly. For example, it will be foolish on my part to build a sprawling campus with 24*7 entertainment facilities for my engineering team working on XYZ-Search just because Google does it for its employees. No doubt, this kind of environment does have its own benefits, but it comes with its own cost. And being a start-up, my XYZ-Search cannot afford this. So in spite of success for this organizational facilities, I should not be adopting it as-is. Similarly, I notice Google search engine places online advertisements on specific locations on the page such as top, bottom, right navigation panel etc. So if I tell my engineers, UX, and marketing team to start putting such advertisements on my XYZ-Search page then I can easily drop my dreams of tasting success. Why? Because Google is earning those advertisements on the basis of top-class search results that lead to user satisfaction and if I try to replicate that financial model for my XYZ-Search engine service then it will be thrown to trash in a matter of a few days. Always remember, bad quality never goes unpunished!  But I do want to adopt my peers’ success model; so what should I do? In that case, you need to learn to adapt. The concept of adapting means that you tailor the existing product or service as per your needs and requirements that suit you best. We know, this is a required thing to be done else it leads to the problem of force fitting leading to a lot of other issues such as employee dissatisfaction, customer drain, regulatory non-compliances etc. To continue with our example of internet search engine service, if our very successful competitor, Google, decides to set up a 24*7 customer care number that provides personalized attention to each caller, then obviously, this initiative is going to win a lot of appreciation from the clients for Google. Who does not want a personalized support and care in business especially if things are not working as expected? But it would be foolish on our part to adopt this model in its entirety; in fact even suicidal for our startup that is already tight on cash inflow and is in primitive stages of internet search engine service development and release. So how do we adapt here?  Because adopting this wonderful idea is a no-brainer; it would be stupid to not implement this. But how to make it fit for us? That is where your SWOT analysis comes into picture. SWOT stands for strengths, weakness, opportunities and threats. How will this help us fulfill our needs? Let’s see.  SWOT analysis to Adapt the Adopted SWOT analysis is helpful here because it will help us nail down the reasons why we want to adopt a best practice, what are our current challenges to be solved through this, what are the constraints that limit our ability to go beyond what is currently possible and what benefits we are going to reap if we are successful. Let me show you an example of this internet search engine service 24*7 customer care with personalized attention. What are our Strengths? Here we or anyone is supposed to list down the aspects that are your strong points for a given situation. You will need to involve more than 3 but less than 10 people in this exercise to get some tangible outcomes. Let’s give it a try. 1) We are a startup with limited and very minuscule customer base; since we are just starting up In normal circumstances, this would be considered as our weakness but in this case, this is our strength; see how This implies that the demand to set up 24*7 customer support is almost nil or maybe does not even exist. And that actually cuts down on our cost factor to set this up 2) Our another strength is, in this case, that no one expects us to give a wonderful customer support since we are a startup busy with getting our service correct first. So the pressure to set this up is not there. What are our weaknesses? Here, we list down our weaknesses in this area. 1) We do not have big purse or deep pockets; that means we cannot spend money on getting state of art technical automated customer support setup 2) Our developers are busy in developing next version, and they barely have time to work with customers for live site issues And we do not have the capacity to hire new developers What are the Opportunities? List down the scope of getting ahead in business and on your competitors, if you succeed in this case 1) Since the expectations are low, so if we are able to provide 24*7 customer support with personal attention then it takes our customer ratings higher at a very steep rate. This positive feedback loop in turn would lead us to get more business and hence, bigger market share Wow; didn’t think it that way! 2) Customer feedback loop would allow us to develop features that are more relevant to them and since our customer base is small, the impact of positive reaction would be higher Hence, more business through positive word of mouth What are our threats? Here we list down the threats that might hamper us on this journey or worst still, the losses that we may incur if we fail. 1) The much-needed finance would be diverted for something that was not asked for in the first place. 2) We are opening up another input channel for our engineering team through customer feedback and not to forget, our engineering team is already overloaded 3) Increased business might become a bane for us if we don’t keep up with the same quality of customer care going forward, and we might lose business due to that. Now, our SWOT analysis is done; and what is the result? That depends upon you and your risk appetite. Now, you should have a discussion with your team and managers and stakeholders and arrive at the best way to go forward depending upon the above SWOT analysis. And before you realize, you will have a perfectly adapted version of a best practice in your hands for your benefit! ☺ All the best! By the way, if I were you, I would have chosen to implement this model of personalized attention to all customers but only during specific hours of the day along with specific modifications to engage with other countries’ customers.    
ITIL Practitioner: Importance of “Adopt and Adapt” Principle and SWOT analysis
Author Image
ITIL Practitioner: Importance of “Adopt and Adapt” Principle and SWOT analysis

ITIL Practitioner: Importance of “Adopt and Adapt” Principle and SWOT analysis

Abhinav Gupta
In my previous posts on ITIL Practitioner, we walked the journey of basics of ITIL practitioner, then emboldened by our little endeavor, we explored core competencies of ITIL, 9 guiding principles and...
Continue reading

ITIL Practitioner: Core Competencies, Guiding Principles and Service Strategy Importance

In my previous post, I wrote a beginners article for ITIL practitioner. There I spoke about how ITIL practitioner certification fits in the entire ITIL framework, we briefly touched upon the examination format for ITIL practitioner course, I wrote about what benefits you and your company can have if you choose to take ITIL practitioner certification and most importantly, I tried to answer the question, “whether you should choose to go for ITIL practitioner certification or not”. Now, in this post, I will try to delve a bit deeper into the other but very important aspects of ITIL practitioner course and those are following: What are the core competencies of ITIL Practitioner Various guiding principles of ITIL Practitioner And to answer the question of the previous post- “Why service strategy is considered the core of ITIL and ITSM framework” Let’s start! Core competencies of ITIL Practitioner: Core competencies refer to the major engine behind ITIL framework. All the processes, steps, functions and techniques revolve around these competencies in the ITIL universe. These three core competencies are as follows: Critical competency Guiding Approach CSI or Continual Service Improvement Critical Competency talks about the critical requirements that any member or professional or organization should possess if they want to achieve success in their service-based projects. Those competencies have been categorized into 3 sections: Communication Organizational change management Measurement and Metric I personally, like to refer to them as CMO [for the ease of memorization]. As expected, communication refers to the paradigm where every individual in your team/project is able to articulate his/her needs, wants, requests in a clear concise manner and as well as to be able to decipher the sender’s message in its accurate form of meaning. Not only this, it also covers the area where the project manager or the project owner needs to ensure that communications to all stakeholders, customers, internal or external are handled properly, documented for future reference and lead to overall service satisfaction. Measure and Metrics deals with the obvious concept that what you can’t measure, you can’t improve. Hence, you will not be able to gauge with accuracy if your service is providing the benefits or not, if your project is on track or not or if the service that is eating resources is performing its intended job or not. For example, an internet search engine service might be able to return more than 1000 results for the most basic of queries. But whether those results are relevant to the user or not will decide the fate of your internet search engine company. In the above case, the internet search engine service is doing the job well by returning more than 1000 results to choose, but if none of those results are the ones user is looking for then it is a failure. And you will not be able to know if you can’t measure effectiveness, efficiency, user satisfaction etc. Hence, measurement on the scale of defined metrics is very important competency to have in ITIL. Organization change management depicts an organizational structure that deals with change management for the service you are providing. Let us continue with the example of Internet search engine service.  Once you could identify, through Measurement and Metrics, that your service was not returning relevant results for your users, then obviously you will engage your engineering team to work on the improved service design. New service design will require changes in the existing search engine code, infrastructure and may be configurations as well. Not all changes, can be, should be and will be approved. Right? We all know that. So there needs to be a change management board for your organization [or project] that will discuss the merits and demerits of all the proposed changes, prioritize them as per business benefits and costs involved, then finally give go-ahead or not. This is what organizational change management is all about. No service management project or organization can succeed if they do not have these 3 competencies sorted out perfectly. And that is where your role as an ITIL practitioner becomes important. Guiding Principles of ITIL Practitioner Now since your project and organization has entrusted you to get the service management perfect and set the core competencies in place and get the parts moving, being a thorough professional and an ITIL practitioner, you will do those perfectly well. Because you have the knowledge required to do this. But what should be your guiding principles for the situations that are not mentioned in the ITIL practitioner guide, what should decide your way forward when you will encounter roadblocks resisting change, and what values should you believe in before you explain the needs of these improvements to stakeholders. And those mantras to guide you in difficult, uncertain, moralistic situations are known as “Nine Guiding principles of ITIL Practitioner”. I personally believe that even if you lose your ITIL practitioner guide [which I hope you don’t because it is not cheap] or if you forget the technical knowledge, as long as your guiding principles are correct you will never falter on your journey. Those principles are as follows: Focus on Value: Always try to look beyond materialistic gains. Look for long-term value. Will it help the organization in long run? Will it solve some genuine problems? Will your customers/users thank you for it? Design for experience: Always ask your designer to keep themselves in the user’s shoes and try to use the service as if they were them. Then check if this current service is being helpful to them or not. This actually helps eliminate a lot of faux pas that actually look good in presentation but are miserable failures when released to the market. Start where you are: There could be multiple interpretations to this statement, but in simple terms, it states, do not forget who you are, where you come from and what your current ground reality is. If you are clear about these things, then more often than not, you will make correct plans. Work Holistically: Always remember, your work and your service not only help solve a problem, but it interacts with a lot of other components in the ecosystem also whether technical, mechanical, and emotional or culturally. So work holistically. An internet search engine may provide accurate results, but in a country where those results are banned or are offending the audience’s religious faith can seriously backfire on you and your organization. Progress Iteratively: Always break the problem into smaller pieces and achieve one or two steps at a time. This helps you get user feedback and improve your service at a low cost, rather than creating the whole service and finding out that there is no market for it. Observe directly: What if you rely on sources to get you the feedback or user reactions or problems data and later on find out that the “source” did not understand the feedback properly, leading you to make something that was not required at all. Or worst, the “source” had vested interest and now your service is out of the market. So don’t take the risk. Focus more on getting the data directly. Be Transparent: Good or bad, whatever be the situation, it should be clearly communicated to your stakeholders. All the decisions along with their rationale should be explained to the audience. Precaution should be taken to not divulge unintended information to the unintended audience. Still, there should be transparency. For example, you got a feedback that in the Middle East your service was gaining negative publicity due to the search results being rendered on a particular topic in spite of the government directive against doing so. In such cases, you are expected to inform your stakeholders about the situation, your plan to tackle it and to inform the end user about the upcoming change. You need to explain the exact problem and its implication to the business users, but you need not maintain the same detailing while sending out communication to market users. So use your filtering mechanism but ensure that transparency is maintained. Collaborate: Not everybody has answer or solution to everything. So better to get best people for their competencies and sometimes, more minds can give you better results. So mix and collaborate. Simple! Keep it simple: Means keep things simple and do not overcomplicate them for showing proficiency. And finally, continually improving service talks about the goal where you have to keep finding ways to improve your service through measure and metrics via communication and organizational change management. So these are the 3 competencies of an ITIL practitioner along with their 9 guiding principles- Why is service strategy the core of ITIL Practitioner? You will be amazed by the answer! It keeps in line with the 9th guiding principle of ITIL. And that principle was: Keep it simple! And this is the reason, I did not answer this question up until now. The answer is: Service strategy deals with the knowledge of what service are you [as a company] going to create through this project and why. It talks about the plans to be executed to develop this service, how to market it, how to provision it, what business benefits will it drive for users and for the organization. So once you have that clear, all your plans, processes, techniques need to be modified to align with that goal, else there is no point of creating an internet search engine service that gives wrong results to the user even if it works very fast.  And this is the reason why Service strategy is the core of ITIL practitioner. Because you need to make it clear to the team you are going to work with!  
ITIL Practitioner: Core Competencies, Guiding Principles and Service Strategy Importance
Author Image
ITIL Practitioner: Core Competencies, Guiding Principles and Service Strategy Importance

ITIL Practitioner: Core Competencies, Guiding Principles and Service Strategy Importance

Abhinav Gupta
In my previous post, I wrote a beginners article for ITIL practitioner. There I spoke about how ITIL practitioner certification fits in the entire ITIL framework, we briefly touched upon the examinati...
Continue reading

Project Management Professional [PMP]: What’s new in 6.0?

Project Management Professional certification, popularly known as PMP certification, is an internationally recognized certification introduced by Project Management institute [PMI] in 1996 as version 1.0   This world recognized, multi-industry approved, cross-functional and much respected certification is currently in its 5th version with 6 updated version announced on 6th  September, 2017 by PMI.   From 2018, PMP certification will be following the guidance issued by PMI in PMBOK® - 6.0th Edition.   PMBoK stands for Project Management Book of Knowledge and can easily be considered as Holy Book for Project Management Professionals. This books defines, discusses and lays down all the project management principles to be followed by professionals throughout the project from initiation to closure.   This post is about discussing the new introductions and changes in the PMP certification and hence in PMBOK® - 6.0th Edition. It goes without saying that this post assumes you are already well-versed in the history of PMP, PMI, knowledge areas, Process groups and most probably, you are already certified or in the process of getting PMP Certified.   Later, I will write some more on the other topics based on your feedback; but for now, let us discuss PMP 6.0 i.e. PMBOK® - 6.0th Edition changes as announced by PMI on 6th September, 2017.   Why the changes are required in PMP certification or PMBoK?   Since its introduction in 1996, PMP has undergone 5 revisions and this is the sixth one. This revision happens every 3 to 4 years as shown below.  1996, PMBOK® - 1st Edition 2000, PMBOK® - 2nd Edition 2004, PMBOK® - 3rd Edition 2009, PMBOK® - 4th Edition 2013, PMBOK® - 5th Edition  As you can see, there is a method to the madness [as I love to call it]. The revision happen regularly every 4 years. This is because PMI is a distinguished member of ANSI [American National Standards Institute] organization; and this membership requires PMI to update its guidance and book of knowledge every 3 to 5 years. Hence this explains the frequency of updates. Generally what kind of updates come in revisions?   PMP certification and project management Book of Knowledge is not restricted to any specific industry or domain. It lays down the best of practices that are certified by Industries, organization to be the most optimum practices for efficient project management.   You can take any industry; be it Manufacturing, or service; all these best practices apply to all companies uniformly. Hence, PMP certified professionals are in great demand across the globe for their knowledge and ability to work across domains, factories, industries and geographies, due to their usage of uniformly approved terminologies and processes.   In every revision, PMI comes up with learning from latest advances in technology across sectors, updates in governance policies introduced by ruling authorities, updates in the best practices based on the results of last few years and introduction of new concepts that have a potential to be big game changers in project management.   Hence, the updates can be categorized in following manner:   1) New learnings and processes introduced in recent times   2) Updates to best practices based on the results of last few years   3) Updates in processes based on recommendations from standard and authorized bodies across the world   4) Game changer items that are going to be critical in project management.   What are the changes in PMP 6.0 or PMBOK® - 6.0th Edition?   Change # 1: AGILE is now officially part of PMBOK® - 6.0th Edition  AGILE has been creating ripples  across the industries and projects for quite a few years now. PMI has recognized the trend and its potential to transform the way projects of future are going to be managed. There is going to be a dedicated booklet for AGILE, being shipped along with PMBOK® - 6.0th Edition  Change # 2: PMI Talent Triangle   PMI defines talent triangle as trinity of principles to achieve success in the project  As the name hints, it consists of 3 processes Process, People and Technology and how they can be combined together to achieve success PMI discusses this concept in details in the 6th version  Change # 3: Process groups are now 49 processes instead of 47  “Manage project knowledge” has been introduced to define how the knowledge accrued in Project execution can be managed “Control resources” has been introduced to control the resources. Note the usage of word control instead of manage “Implement risk responses” has been introduced as a separate process to manage the responses received during risk analysis. Earlier this was an activity; but now it is a full-grown process in itself owing to increasing uncertainties of projects in current times. “Close procurements” has been deleted. This was a separate process earlier but no more.  Change # 4: Renamed multiple process to reflect the current situation of project management  “Project Human Resource Management” has been renamed to “Project Resource Management”, because resources can also include non-human resources such as electronic devices, software, infrastructure and logistics. “Project Time Management” renamed to “Project Schedule Management” because  schedule management needs to consider constraints on resources, risks, material and time. Hence the word “schedule” is more apt than “time”. “Perform Quality Assurance” changed to “Manage Quality” to reflect the development in thinking that Quality assurance is not a simple activity that you can perform in one go. Quality assurance in an independent career in itself. So this should be managed. “Plan Human resource management” changed to “Plan resource management” is self-explanatory because resources need not be only human. “Acquire project team” has been renamed to “Acquire Resources” “Control Communications” is now “Monitor Communications” to indicate the relaxation,and is debatable because here it takes out the onus of controlling the communications from Project manager and puts it on the team to conduct their communications in a responsible manner. “Control Risks” has been renamed to “Monitor Risks”, because managing risk response has been created as a new process. “Plan Stakeholder Management” is now “Plan Stakeholder Engagement”. Every good project manager knows that stakeholders need to be engaged with at multiple levels rather than simply managing them through reports and status meetings.  “Control Stakeholder Engagement” to “Monitor Stakeholder Engagement” to reflect change in the notion that project management should monitor such engagement rather than being heads-down in controlling them. Change # 5: Role of project manager in a project gets a chapter for itself   This time, PMI spends a chapter on the topic of the role and responsibilities of project   manager as a whole. This is a big deviation from the old times, where PMBoK considered Project manager as a whole sole owner of project. But this time, PMI has expanded the definition of project manager and given him/her a broader role of a guide, mentor and monitor. Change # 6: Distinctions between most commonly mistaken terminologies such as:   On-Going and Non-Ongoing processes  Project Scope and how it is different from product scope  Communication and communication(s) Change # 7: Introduction of Risk response escalation strategy Here it discusses how to escalate the risk and its corresponding actions to the concerned stakeholders and multiple ways to handle this.  So these are 7 major changes in PMP certification and PMBOK® - 6.0th Edition; all of these changes will come into effect in the first quarter of 2018.   If you are planning to get certified before December, 2017 then continue to refer to PMBoK ® Version 5, else start referring to version 6.   In short, I can easily see that PMI has defined the role of Project manager to be more of a guide, allowing greater independence to the execution teams and at the same time, it assigns the tasks of responsible, correct communications, managing the risks to the team rather than only on PMs.   PM, in turn, has to coach the team to identify and plug the holes in their executions, plans and strategies.   The new version of PMBoK is definitely a step towards better and cohesive coordination between project management team and execution team, ensuring success through optimal usage of technology i.e. PMI Talent triangle!   All the best!   Feel free to write to me for questions and clarifications.  
Project Management Professional [PMP]: What’s new in 6.0?
Author Image
Project Management Professional [PMP]: What’s new in 6.0?

Project Management Professional [PMP]: What’s new in 6.0?

Abhinav Gupta
Project Management Professional certification, popularly known as PMP certification, is an internationally recognized certification introduced by Project Management institute [PMI] in 1996 as version ...
Continue reading

Use Cases: How Are They Different From User Stories & How To Create Them

I could have used the word, “write” instead of “create” use cases. But I didn’t. If you know why, then you are already expert on this topic, so please do share your opinion and knowledge by adding some comments at the end of this article. If you don’t know why I consciously mentioned “create” instead of “write” then worry not. I will share my thoughts  with you and you can tell me what you think and let’s create a dialogue around it. In my previous article, I had written about user stories, and how they came into extensive usage, how they help develop better products and how they represent users’ voice at forums users don’t have access to. If you have not read that article then I would sincerely request you to read that article first as it will immensely help you in getting the right perspective about this topic at hand. Use cases in simple words are exact statements written in informal manner depicting the specific action that the user is expected to do while dealing with a particular functionality of the product. If you compare this with the definition of user stories I gave in my previous article, you will notice that here I have defined use cases as “exact statements” whereas I had defined user stories as “generic statements” written in informal manner. Why? This is because user stories set a foundation upon which great use cases are created or developed. While user stories try to explain to the engineering team about the environment, goal, role, intention of the user while he/she is going to deal or work with the software; use cases clearly define what the user is going to do here and what result is expected in crisp 2-3 lines. Use cases are one level above requirements. Below is a simple table for quick reference on differences between user stories and use cases. A simple example of creating use cases from user stories: Let us take a very simple example of a toothpaste and let’s create use cases out of it. If you want to see how to develop user story then please read my earlier article on user stories. Always remember, while it will seem easy to create use cases directly from user needs; it is full of pitfalls that might lead to missed functionality and user dissatisfaction later on, after shipping the product. So a user story would look somewhat like this: Actor  :    John, a working professional who wants to keep his teeth health and shiny Role    :    The direct consumer of this product but can influence others by his reviews of a product on his website. Expected results: After brush, John expects his breath to be fresh and teeth and gums to be health for the whole day. Now as you can see, John is a very high impact user for us [The toothpaste company] because he can affect our sales by his review of our product on his website. So meeting his needs are very critical for us. Hence the product manager, should create following user story for this scenario. Sample User Story: It is 6:30AM in the morning and John has started his morning rituals to be ready for work. Daily, his first routine after waking up is to brush his teeth with his favorite toothbrush so that he gets the refreshing feel to do remaining chores around the house and leave for work on time. He likes the way toothpaste, smoothly oozes out of the tube and rests firmly on this toothbrush without spilling anywhere. Also he likes that somehow, every time he brushes, the exact right amount of the paste comes out of the tube. It is never too much and never too little. It’s just right. He feels energized after a refreshing brush ritual and likes the feeling of freshness in his mouth after brushing his teeth. His gums feel rejuvenated, breath feels fresh as he tests it out on his palms. After spending whole day at office, where he had multiple cups of coffee, some food and some sugary items, he comes back home. While refreshing himself, he notices that his breath is still fresh and the taste in his mouth is still neutral without any traces of coffee or cheese pizza he had before. He is so pleased with the product that he has bought for himself, that he decides to write about it in his blog tonight. Now let us create some use cases out of the above user story. Use case 1: User wants to have a premium quality feel when he/she takes the toothpaste tube in their hand before brushing. Use case 2: User gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube. Use case 3: User is able to notice the right amount of paste coming out of the tube every time, he/she brushes. It is never too much nor too little. One gentle squeeze always gives out the right amount of paste required for brushing. Use case 4: User feels an air of freshness in his mouth after brushing and that freshness lasts for minimum of 24 hours. The feeling of freshness is neither overwhelming nor un-noticeable. It is just mild   enough to provide a feeling of freshness while not interfering with user’s culinary habits. Use case 5: The user is pleased with the fact that the teeth and gums feel very smooth and non-scratchy after every brush. Use case 6: User is happy about the fact that even after 12 hours of intense work day routine, his breath still feels fresh And so on and so forth.  Can you think of some more use cases? If yes, do leave your comment below so that we can discuss on their validity and applicability here. Is the concept of use cases starting to make itself clear to you now and how they are different from user stories? Let us try once more. This time let us try to create use cases of this same product but for different customer base. Sample 2 of creating use cases for a product: This time, instead of a working professional, John. Let us consider Alayah, a teenage girl in high school. Actor :    Alayah, a 16 year high school student who is interested in experimenting new things with regards to body hygiene for better well-being and feeling. Her opinion is slightly influenced by the           feedback of her friends and her own personal experiences as she too likes to share her feedback with them. Role :    A direct consumer of our product and her feedback can motivate others in her circle of influence to try out our product. Expected Results: While healthy teeth and gum are the most basic of her requirements, she is bored with the same tasting toothpastes on offer these days. She wants to try out a new toothpaste that     not only provides her with best dental protection but also convinces her Mom of her ability to choose different but a better product by herself. Here, our engineering team’s task is clear. They need to create a product [toothpaste in this case], that not only impresses Alayah but also provides her with the best dental protection that she needs at her age. Her feedback carries the possibility of our product’s adoption by her immediate family members and her close friends, hence opening the market for us. The product should be unique in itself while being the best in terms of quality at cost effective price, since Alayah is not an earning member of her family. A product manager in this case, will have lot of options to think of a product here and specify to the engineering team. Let us go with one of them. Do share your versions of user stories in this case. User story: It’s morning time and Alayah’s alarm is ringing she had set last night to wake her up on time, if she needs to make it to the school without being reprimanded. She quickly jumps into the shower with a toothbrush having toothpaste on it, while her favorite song is playing out on her personal stereo. While she is freshening up, she is delighted with the fact, even after so many days, her toothpaste continues to give out the same wonderful strawberry flavor that she loves so much. And to add to her delight, her dentist gave her a big thumbs up yesterday on her teeth and gum health. Alayah has been using this toothpaste for a month now and she loves the way, the tube feels like new everyday even after so many uses. She never has to squeeze hard to get the paste out of it. One gentle squeeze and strawberry colored toothpaste gently but firmly oozes out of the tube and rests on the bristles of the brush. Earlier, she used to get lot of scolding from her mother on spilling the paste around the sink, while jumping into shower with toothbrush and paste on it. But ever since, she switched to this new toothpaste, there has not been a single spill ever since. Today, she is definitely going to tell her Mother to make permanent switch to this paste. She will recommend the butterscotch flavor to her Mom because she loves it. Wow! A wonderful experience of morning ritual for Alayah’; isn’t it? Let us create use cases for this one. Use case 1: User is delighted with the fact that tooth paste comes in a flavored version and the flavor of the paste is consistent throughout till the last drop in the tube. Use Case 2: User is experiencing a natural growth in well-being of her gums and teeth due to the regular usage of toothpaste and is certified by her dentist also. The noticeable difference comes out in 1 month of regular usage. Use case 3: The user is happy about the quality of the product and feel of it. The flow of the paste is smooth, uniform and consistent. It is firm yet soft to the right degree and grips the bristles of the       brush firmly without leaving behind any residue. Use case 4: The user is happy with the non-slipperiness of the paste as it holds wells on the toothbrush without spilling on to the floor. Use case 5: The user is going to recommend the product to her family members owing to its cost effectiveness, quality of results and number of flavored options available to choose from. In this case, the product manager’s diktat was clear. The toothpaste should be premium feeling with right amount of firmness, variety of flavored options to choose from, health improving and certified. And how did we learn properly? Because we were able to create user stories and use cases properly depicting the right user environments, their interactions with the system and their expected goals from these interactions. This is how use cases add value to the development of right product whether it is software based or manufacturing based or service based. So next time, when you want to ship to the customer, make sure you have all the right user stories targeting the right audience with complete use cases and your product will be a smash hit. This is why, I said, a product manager “creates” use cases and does not merely “write” them. Because while creating use cases, the product owner gets the feel, intent of the product that will surely be missed out if he/she is merely jotting down the requirements or use cases. In my next article, I will share with you on how requirements come out of use cases. Until then, happy creating user stories and use cases and do share your experiences with me on my email or in the comments’ section below. Thank you for your time!  
Use Cases: How Are They Different From User Stories & How To Create Them
Author Image
Use Cases: How Are They Different From User Stories & How To Create Them

Use Cases: How Are They Different From User Stories & How To Create Them

Abhinav Gupta
I could have used the word, “write” instead of “create” use cases. But I didn’t. If you know why, then you are already expert on this topic, so please do share your opini...
Continue reading

SUBSCRIBE TO OUR BLOG

Share Blog

View All Topics

Follow Us