Search

Is The Confirmation in the 3Cs Of User Stories Making The Implementation Team Over Dependent?

Writing requirements as user stories is the most common and accepted form of documenting requirements in an Agile project. Moreover, product backlogs are made up of requirements written as user stories most of the time. User stories are considered to be simple to create, clear and concise and easily understood, and considered as convenient to update and maintain. User stories are written following a specific format, making it universally acceptable across the software industry. User stories follow the 3C’s format described below and focus on the business value each story provides to the user. 3C’s of user stories Card The first C, ‘Card’ simply means that the user story must be small enough so that the content can fit on a small business card size board / paper. The user story takes the following format.                                                                   As a [user | role | persona]                                                                I must be able to [functionality]                                                              So that I get [benefit | business value] As best practice, we try to generalize by writing the requirement as required by a user group or role. For this it is imperative that ‘user research’ is done to capture the actual behaviours, opinions and attitudes of the users and be documented as ‘user persona’ documentation. The functionality is documented with the keyword ‘must’ which stresses the fact that this is the exact feature required by the user. Some document the functionality with keywords such as ‘will’, ‘shall’, ‘would’, ‘should’ etc which actually leaves a bit of uncertainty and must be avoided at all times. When documenting the benefit or the business value it is always good to keep in mind the ROI, cost saving, efficiency etc expected from the feature described. The user story as we can see is a combination of ‘who’, ‘what’ and ‘why’ which together gives out a meaningful story. The user story defines functionality from a business perspective and does not define how the problem shall be solved. Conversation It is said to define a user story with enough detail to start development and less information to arouse discussion. Conversation must happen between the user and the implementation team as well as between the members of the implementation team and must be aimed at digging deep into the unstated and implied requirements of the customer. A good conversation would surely help unearth the creative side of the implementation team and whatever is unearthed, relevant or irrelevant must be listed down as additional information on the card. Confirmation Now we come to the most controversial component of the 3C’s – Confirmation. It is all about writing acceptance criteria. This is the section where the team or business analyst in most cases, is expected to detail out the business and validation rules, exact specification of the requirement, and sometimes even the step by step description of how to realize a certain requirement. The team may even write examples of particular scenarios if it involves complex processing and calculation. Teams are still fighting to keep the acceptance criteria as detailed as possible to that of a traditional detailed requirements specification and sometimes even maintain checklists of possible aspects to look for in defining requirements. A user story and its possible acceptance criteria can be as below. As a backpacker I must be able to search for rest houses so that I can identify a suitable place for my stay. Acceptance Criteria: Search for rest house by location, price range, facilities, cuisine, surroundings, rating Customize search as required Compare rest houses All key information to be available at one glance But writing acceptance criteria in detail like this is never a good idea. There is no such thing as a complete or exact specification. A user expectation may not be defined in exact detail or accuracy all the time. Space must be kept for the team to have a good conversation to uncover hidden aspects about the requirements. As we can see from the above example itself we are unable to confidently say that we’ve covered the requirement to its entirety. For example, ‘what are the key information to be displayed and be available as a single view?’. With this approach, the development team is never involved in story definition. They end up being spoon-fed, take the criteria one by one and implement as is. The main reason being they being able to blame the poor business analyst for not detailing the requirements adequately. It should ideally be a case where the requirements and the entire organizational change is driven by the business analyst and to have him involved collaborating and communicating identifying the change required to meet the customer needs throughout the life of the project. So, what is a better approach? As explained before, the user story is about striking a conversation. Keep the story simple and short stressing on the expected behaviour and impact. These can be written as ‘Conditions of Satisfaction’. For example, ‘The backpacker can enjoy a nights stay after a tedious day at a budget hotel at a convenient location’. Now, the team as a whole will be focused on solving the ‘problem defined’ by having a more user centric conversation. More user research will be done to identify solutions to address the user needs and in determining new ways of delivering more value. Discussion may take longer but ultimately, the team shall produce winning solutions that are geared to solving the real problem at hand. So, it is up to you now to use your user stories wisely. ☺
Rated 4.0/5 based on 20 customer reviews

Is The Confirmation in the 3Cs Of User Stories Making The Implementation Team Over Dependent?

1K
Is The Confirmation in the 3Cs Of User Stories Making The Implementation Team Over Dependent?

Writing requirements as user stories is the most common and accepted form of documenting requirements in an Agile project. Moreover, product backlogs are made up of requirements written as user stories most of the time. User stories are considered to be simple to create, clear and concise and easily understood, and considered as convenient to update and maintain.

User stories are written following a specific format, making it universally acceptable across the software industry. User stories follow the 3C’s format described below and focus on the business value each story provides to the user.

3C’s of user stories

  1. Card
    The first C, ‘Card’ simply means that the user story must be small enough so that the content can fit on a small business card size board / paper. The user story takes the following format.

                                                                  As a [user | role | persona]

                                                               I must be able to [functionality]

                                                             So that I get [benefit | business value]

As best practice, we try to generalize by writing the requirement as required by a user group or role. For this it is imperative that ‘user research’ is done to capture the actual behaviours, opinions and attitudes of the users and be documented as ‘user persona’ documentation.

The functionality is documented with the keyword ‘must’ which stresses the fact that this is the exact feature required by the user. Some document the functionality with keywords such as ‘will’, ‘shall’, ‘would’, ‘should’ etc which actually leaves a bit of uncertainty and must be avoided at all times.

When documenting the benefit or the business value it is always good to keep in mind the ROI, cost saving, efficiency etc expected from the feature described.

The user story as we can see is a combination of ‘who’, ‘what’ and ‘why’ which together gives out a meaningful story. The user story defines functionality from a business perspective and does not define how the problem shall be solved.

  • Conversation
    It is said to define a user story with enough detail to start development and less information to arouse discussion. Conversation must happen between the user and the implementation team as well as between the members of the implementation team and must be aimed at digging deep into the unstated and implied requirements of the customer. A good conversation would surely help unearth the creative side of the implementation team and whatever is unearthed, relevant or irrelevant must be listed down as additional information on the card.
  • Confirmation
    Now we come to the most controversial component of the 3C’s – Confirmation. It is all about writing acceptance criteria. This is the section where the team or business analyst in most cases, is expected to detail out the business and validation rules, exact specification of the requirement, and sometimes even the step by step description of how to realize a certain requirement. The team may even write examples of particular scenarios if it involves complex processing and calculation. Teams are still fighting to keep the acceptance criteria as detailed as possible to that of a traditional detailed requirements specification and sometimes even maintain checklists of possible aspects to look for in defining requirements.

A user story and its possible acceptance criteria can be as below.
As a backpacker I must be able to search for rest houses so that I can identify a suitable place for my stay.
Acceptance Criteria:
Search for rest house by location, price range, facilities, cuisine, surroundings, rating

  • Customize search as required
  • Compare rest houses
  • All key information to be available at one glance

But writing acceptance criteria in detail like this is never a good idea. There is no such thing as a complete or exact specification. A user expectation may not be defined in exact detail or accuracy all the time. Space must be kept for the team to have a good conversation to uncover hidden aspects about the requirements. As we can see from the above example itself we are unable to confidently say that we’ve covered the requirement to its entirety. For example, ‘what are the key information to be displayed and be available as a single view?’.

With this approach, the development team is never involved in story definition. They end up being spoon-fed, take the criteria one by one and implement as is. The main reason being they being able to blame the poor business analyst for not detailing the requirements adequately. It should ideally be a case where the requirements and the entire organizational change is driven by the business analyst and to have him involved collaborating and communicating identifying the change required to meet the customer needs throughout the life of the project.

So, what is a better approach?

As explained before, the user story is about striking a conversation. Keep the story simple and short stressing on the expected behaviour and impact. These can be written as ‘Conditions of Satisfaction’. For example, ‘The backpacker can enjoy a nights stay after a tedious day at a budget hotel at a convenient location’.

Now, the team as a whole will be focused on solving the ‘problem defined’ by having a more user centric conversation. More user research will be done to identify solutions to address the user needs and in determining new ways of delivering more value. Discussion may take longer but ultimately, the team shall produce winning solutions that are geared to solving the real problem at hand.

So, it is up to you now to use your user stories wisely.

Rumesh

Rumesh Wijetunge

Chief Innovation Officer - Zaizi Limited, Chief Operating Officer - LearntIn (Pvt) Ltd., Director /

Rumesh is an IT business leader with over 12 years of industry experience as a business analyst and project manager. He is currently the CIO of Zaizi Limited, a UK based data management company heading the operations in Sri Lanka, the COO of LearntIn, a global training institute based in Sri Lanka and is also a lecturer / trainer at multiple private universities on management, IT, business analysis and project management subjects. He is the current president of the IIBA Sri Lanka chapter and is one of the most qualified and sought after trainers in Sri Lanka. Refer his LinkedIn profile for more details and to see more articles he has written on linkedin

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

Why Do We Use Fibonacci Series for Estimation

In this article, my focus is on sharing my experience as a Trainer/Mentor/Coach to Agile teams with respect to Agile estimations; and on using the Fibonacci sequence as scale to size the Story. What will you learn in this article? Agile practitioners mostly use Story points as a measure for estimation, typically using the Fibonacci scale. In this article we are going to understand the top reasons why we use the Fibonacci series for estimation, and how it works in practice. Before we get to the details, let us try to understand some of the fundamentals. Why do we need to estimate?Estimates help the project team to: Identify the time & effort required to arrive at the project schedule Identify the right number of people required to do the work Arrive at the budget by rolling up the cost of all activities required to complete the work; and Prioritize the work in conjunction with the value that will be delivered. Some software developers fear to provide effort estimates as they are accountable to complete their work within the time.  Hence, they take so much time to get into the details to make sure they have enough information to provide the estimates. This sometimes may not be possible during the beginning of the project as the team may not have enough information on hand to provide the effort estimates for all the tasks to be performed. Hence the order of magnitude (ROM, Budget or Definitive) will be applied at various stages during the project based on the available information to predict the effort needed to complete the activities. Agile Estimation  Typically, in traditional project management, effort estimations may or may not be agreed upon by the entire team. Estimates may either be given by the Project Manager/Tech Lead to the team or the developers/testers may estimate for the piece of work that they have been assigned. This way of estimating a project does not provide an opportunity for the team to collaborate. There may be a difference of opinion with the team members in the effort that need to be spent on an activity. The way the estimations are done within an Agile team is little different. It is just not about the measure used to estimate the effort (for example Story Points), but ensures that the team collaborate among themselves, thus providing an opportunity for knowledge sharing. This helps the accuracy of the estimates when compared to doing individual vs group estimates as the team members come from different backgrounds and roles (developers, testers, quality analysts, business analysts). An Agile team effort estimate focuses on relative sizing of user stories and does not focus on the duration; hence it is faster. The team learns to size the story relatively and accurately over a period of a few iterations (sprints), thus improving the predictability (arrived through establishing consistent velocity over a period of few iterations) as well.  Planning Poker is commonly used as the planning exercise for the team to collaborate and size the stories. Planning Poker uses Fibonacci sequence to assign a value to the epic/feature/story. What is Fibonacci Series?  According to Oxford dictionary, Fibonacci Series is : “ a series of numbers in which each number ( Fibonacci number ) is the sum of the two preceding numbers. The simplest is the series 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 etc” The formula to arrive at a Fibonacci sequence is: Xn = Xn-1 + Xn-2 This sequence will be slightly modified when used in Agile estimations: typically, it will not have values beyond 100 and may have 0, ½, 1, 2, 3, 5,8, 13, 20, 40, 100. Some teams limit the highest value as 21 and use 0, 1/2, 1, 2, 3, 5, 8, 13, 21. Top 3 Reasons Why Using the Fibonacci Sequence Will Make You Better at Estimating Tasks  1. Weber–Fechner law: “The Weber–Fechner law refers to two related hypotheses in the field of psychophysics, known as Weber's law and Fechner's law. Both laws relate to human perception, more specifically the relation between the actual change in a physical stimulus and the perceived change. This includes stimuli to all senses: vision, hearing, taste, touch, and smell” Applying the law to Numerical Cognition,  “Psychological studies show that it becomes increasingly difficult to discriminate between two numbers as the difference between them decreases. This is called the distance effect. This is important in areas of magnitude estimation, such as dealing with large scales and estimating distances. It may also play a role in explaining why consumers neglect to shop around to save a small percentage on a large purchase, but will shop around to save a large percentage on a small purchase which represents a much smaller absolute dollar amount”  (source: https://en.wikipedia.org/wiki/Weber%E2%80%93Fechner_law) The Fibonacci sequence very well corresponds to Weber’s law. The values in the Fibonacci sequence are about 60% higher than the previous value, and hence applying relative sizing is much easier. It is very challenging to distinguish the size of two numbers which are adjacent to each other, by just looking at the objects. Let us take an example of a football and cricket ball. The approximate diameter of a cricket ball would be 2.8 to 2.86 inches whereas the diameter of a football would be 8.66 inches. It is easy to distinguish the relative size of these two (i.e., approximately the diameter of a football is 3 times that of a cricket ball). However, it is very challenging to distinguish between two cricket balls that vary 1 inch in diameter, unless you measure both. If you look at the Fibonacci sequence, the relative size between two adjacent numbers is more than 60% and this helps us to be able to size them accordingly.   2. Reflect Uncertainty The smaller value assigned from the Fibonacci sequence to a user story usually means that the story is well understood, and the user story follows INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable) guidelines. Whereas the largest value denotes the story is not well understood or it needs to be broken down further. Smaller stories can be confidently estimated by the team in detail. A general practice from matured Agile teams is that the Fibonacci sequence is restricted up to 21 (0,1,1,2,3,5,8,13,21) and any story which is of size beyond 21 will have to be broken down further. This ensures that the team is not giving any room for greater uncertainty and good practice for the team to write better stories under the INVEST guidelines. 3. Comparison Though it is not mandatory to use Fibonacci sequence for story point estimations, the sequence is easier to understand and adoptable by the team. Individuals are better at comparison than estimation.  The easy sequence and distinguishable values of Fibonacci sequence helps to estimate by not measuring the objects but by comparison. How Does Fibonacci Agile Estimation Work in Practice?  When do you think is the right time for the Agile team to estimate user stories that are prioritized by the Product Owner in the product backlog? In my experience, I would say that the estimates (story point sizing) should happen during the Iteration/Sprint backlog grooming sessions. This gives the team the time to go through the user stories in detail, collaborate and mutually agree using the Planning Poker exercise.  Then what do we do in Sprint Planning? – This ceremony should be used to pick the stories from the product backlog (fulfils Definition of Ready), that can be completed within the iteration/sprint and then breakdown the stories into tasks and do one more level of estimation which is effort estimation denoted in hours. Let us say a team is assigned a task to estimate a reporting module to be developed: The team would agree that it is a difficult task to provide an effort estimation and it would take a longer time to complete; but how long will it take? Using Simple, Medium and Complex categorization would simply mean that the estimate falls into the Complex category; but how complex is it? Breaking down the requirement into granularized tasks, getting to the minute details and then arriving at an effort estimation would be a complex process and time consuming as well. Can the team take linear sequence (1,2,4,8,10,12,14,16….) and size them for a high-level estimation? Is it possible to size between 50 and 52? What can be defined as the highest scale? Using Fibonacci series helps the team to size the stories which have a distinguishable value and as discussed earlier, matured Agile teams use modified Fibonacci series and have highest scale of 21 to size a story. As discussed above, the Fibonacci numbers are 60% above than the previous number, and that helps in relative sizing. Summary There are various methods to estimate user stories, like T-Shirt sizing, Dot voting, Affinity Mapping etc. Story points is the widely used measurement for sizing the user stories. Fibonacci series helps the team to compare between two stories; and its very nature of distinguishable values helps them to fit the story into the right size that reflects uncertainties, which further helps the team to refine the story to remove those uncertainties. Hope this article was useful to you.
Rated 4.0/5 based on 13 customer reviews
5903
Why Do We Use Fibonacci Series for Estimation

In this article, my focus is on sharing my expe... Read More

PRINCE2®Agile vs PMI-ACP®: What’s Best for You?

Changing industrial trends and the mass adaptability of agile practices have transformed the way organizations work. Over time, a number of project management methodologies have cropped up to suit different industry needs, and today’s business leaders have a wide array of frameworks to rely upon. This has led to the inevitable need for skilled project management professionals who are well-versed in different frameworks. When it comes to the widely popular Agile methodologies, the presence of multiple certifications in agile / agile project management methods can seem overwhelming to aspiring professionals. This article will give you a comprehensive overview of PRINCE2®Agile and PMI-ACP® (Agile Certified Practitioner) certifications to help you make an informed choice. Project leadingWhat is a Project? Due to the accelerated pace of change, today’s enterprises have to cope with the complexities of emergent requirements over the course of a project. Strategic business decisions are often made after taking stock of competitors’ actions, technological advancements, regulatory changes, ongoing business developments and so on. In order to compete and thrive in the future, existing ways of working must be aligned to adapt to these evolving needs. Example: Today every bank across the globe offers innovative banking products and services like mobile banking applications, ATMs etc. These changes have been adopted to cater to the evolving expectations of customers while adapting to the latest technological advancements. Projects are the means of introducing change. A collective effort from different stakeholders needs to be pumped into the project initiatives to deliver the products and to accomplish the objectives within definitive timescales. Example: The Ministry of Health & Family Welfare of a country is planning to design, build, roll-out and implement a Health ID card system for its citizens within a year. This project will benefit the government and its citizens in various ways. Different organizations such as government, health ministry, hospitals, technology providers have to work collaboratively to implement the product within the identified timescale, cost and quality. Project Manager planningWhat is Project management? When different stakeholders come together to deliver a unique product within an estimated timescale and cost, there should be someone who needs to be accountable and responsible to manage the different aspects of the project.  Project management broadly revolves around key activities such as plan, execute, monitor and control. Management of projects is an art which includes skills like leadership, domain knowledge, interpersonal skills, people management, powerful communication, stakeholder engagement, conflict management, business acumen etc.,  Example: A central library run by a private firm is looking to launch a digitized version of its books. A Project Manager is identified to manage the scope, cost, time, quality, risks, resources, stakeholders, communications etc., from the beginning to the end of the project.  Project managers and their organizations can choose to apply the right methods, tools, techniques, standards, guidance, good or best practices to run their projects.  Why agile in project management?  As digital transformation is catching up with many organizations, business demands are also increasing, and the requirements for products and services is continually evolving as well. To meet the demands of businesses today, project-driven organizations should look for ways to increase the speed of product delivery while upholding quality. Agile project management is an iterative approach to delivering a project throughout its life cycle. The Agile framework helps project managers to stay on top of emergent requirements and adapt to change more readily, delivering products that are better aligned with customer expectations. With agile methods such as Scrum being widely accepted and used in today’s organizations for software development projects, more agility is seen in the delivery teams. Product development in Scrum teams occurs in shorter iterations/timeboxes (2 weeks to 4 weeks). This is because the goal is to deliver minimum viable products (MVP) or a feature/functionality within shorter sprints. Example: As a part of digital transformation, a school wants to launch a mobile app. In the beginning of the academic year, the first section of the app was ready and launched for use. During the launch, it only had a login and a digital diary feature. In the second month, they added a few more features such as timetable, attendance tracker. In the third month, new enhanced features such as progress card, online payment options were added. By the end of six months, the app had varied features to suit the needs of the school, teachers, students and parents and it added value to all categories of stakeholders iteratively.  The Contrast of Waterfall Vs. Agile ways of working:The Contrast of Waterfall Vs. Agile ways of working:The reason for agile’s popularity is because of its ability to address the new demands being placed on the project team.  Prince2 ProcessesWhat is PRINCE2®? PRINCE2® (PRojects IN a Controlled Environment) is widely considered the leading project management method. It is a unique, light weight, scalable, flexible, highly tailorable, principle-driven, agile enabled framework to run your projects.  PRINCE2 revolves around the concepts of principles (value statements), themes (focus areas to run the project) and processes (steps involved to accomplish project objectives).  Let’s get introduced to the PRINCE2 elements: Principles: Continued business justificationBusiness valueLearn from experienceLessons are sought, recorded and acted upon; continuous improvementDefined roles and responsibilitiesAll stakeholders representedManage by stagesProvides management control and realistic planning horizonsManage by exceptionAuthority delegation for directing, managing and delivering within tolerancesFocus on productsQuality-centric approach to planningTailor to suit the projectTailor to suit project environment, size, complexity, importance, risk, etc.Themes:Business CaseWhy?OrganizationWho?QualityWhat?PlansHow?, How much?, When?RiskWhat’s the impact?ProgressWhere are we now?Where are we going?Should we carry on?Processes:Starting Up A ProjectVerify whether the project is worthwhile and viable.Directing A ProjectDecision making, allocation of resources and estimating expenditure.Initiating A ProjectSetting up a firm foundation (controlled environment) for the project.Managing Stage BoundariesPreparation for management review including stage planning.Controlling A StageDay to day management of the work, issues and risk.Managing Product DeliveryProduct creation, delivery and acceptance.Closing A ProjectFinal delivery, acceptance and project evaluation.PRINCE2® Process Flow Diagram:PRINCE2® Process Flow Diagram:Processes are at the core of the PRINCE2 framework. Application of themes, principles and tailoring of the processes makes it easy to adopt and adapt which reduces the bureaucracy of project management. At the same time, it provides the proper governance to keep the projects justified.What is covered in PRINCE2 Agile™?Project EnvironmentIf PRINCE2® is already agile, what is PRINCE2 ® Agile? PRINCE2® Agile guidance is all about tailoring PRINCE2 to incorporate Agile methods. PRINCE2 is a neutral project management framework which can support both traditional waterfall projects as well as agile or adaptive or iterative projects.  To provide guidance on how to integrate high velocity models or practices into the existing projects for both IT and non-IT industries, PRINCE2 Agile considers Scrum, Kanban, Lean approaches. The intention is not to explain all the agile frameworks in detail; but rather is to show practitioners how to amalgamate PRINCE2 with other agile practices. PRINCE2 considers agile as a collection of behaviours, concepts, frameworks and techniques.   In a nutshell, PRINCE2® Agile is basically a marriage between PRINCE2 and Scrum practices.  PRINCE2’s core concepts of principles, themes and processes are tossed up with agile concepts, techniques, behaviours, practices which fuels more velocity into the existing framework.Certification: PRINCE2® Agile has two levels of certification (Foundation and Practitioner) Foundation Exam: Multiple choice 50 questions 1 hour to complete the paper Achieve 28 or more out of possible 50 marks (55%) to pass the exam Closed book exam Practitioner Exam: Multiple choice 50 questions based on project scenario 2 hours 30 minutes to complete the paper Achieve 30 or more out of possible 50 marks (60%) to pass the exam Open book exam. You can use the “AXELOS® PRINCE2 Agile™ guidance book”.  Certification Scheme: Prior project management experience is not required to take up the certification.  What is covered in PMI-ACP®? The Project Management Institute’s Agile Certified Practitioner is a credible certification which provides thorough knowledge to project managers using agile methodologies.  There are many agile practices other than Scrum that are widely used in the industry such as eXtreme Programming, DevOps, Test Driven Development (TDD), Behaviour Driven Development (BDD), Feature Driven Development (FDD), Crystal, Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), Dynamic Systems Development Method (DSDM), Kanban, Lean Product Development etc., Most of these practices revolve around the core concept of iterations with other variations. Most of these practices are ‘IT-only’ frameworks.  Agile mindset and principles play a vital role in executing the projects in a different way as compared to the traditional ways. Right from covering the concepts of agile values, mindset, practices, terminologies, most of the above-mentioned agile models are covered in a greater detail in this program.  Concepts and techniques like agile contracting, agile risk management, earned value management (EVM), cumulative flow diagrams (CFD), estimation techniques, relative prioritization, work in progress (WIP) limits, Kano analysis, product backlog grooming, personas, user stories, story maps, wireframes, product road map, minimum marketable feature (MMF), definition of done, continuous integration, burn charts, stakeholder engagement, leadership, building agile teams, coaching, osmotic communication, timeboxing, planning poker, release planning, problem solving, lead time, cycle time, defect rate, control limits, throughput, velocity, variance and trend analysis, value stream mapping, continuous improvement, retrospectives, learning cycles etc., are imparted as a part of this certification course.Certification: 120 Multiple choice questions 3 hours to complete the exam Closed book exam Prerequisite: Secondary degree 21 contact hours of training in agile practices 12 months of general project management experience within 5 years.  8 months of agile project management experience within the last 3 years. Differences in these certifications:ParametersPRINCE2 AgilePMI-ACPTopics coveredIt is a blend of  PRINCE2® and Scrum.Spans across many approaches of agile.Governing bodyAxelosProject Management InstituteExam bodyPeoplecertPearson VUEExam modePaper-based test, computer-based test and Online proctored examOnline proctored examPrerequisiteNo prior project management experience is required. PRINCE2 Foundation or PRINCE2 Agile foundation certification is a prerequisite for taking up the practitioner exam.Secondary degree21 contact hours of training in agile practices12 months of general project management experience within 5 years.  8 months of agile project management experience within the last 3 years.Training4 days of training from an Accredited Training Organization (ATO) by Axelos3 days of training from a Registered Training Partner (REP) by PMICost of training & certificationApproximately Rs. 40,000 to 50,000Approximately Rs. 40,000 to 50,000Maintaining the certificationFoundation certification has a life time validity. Practitioners need to earn 20 continuing professional development (CPD) points every year.Earn 30 professional development units (PDU) every three years.Merits and demerits of both these certifications: Merits of PRINCE2® Agile:  PRINCE2 Agile provides a good governance model to run the project with guidance on how to incorporate any agile model.  It does not favour one agile approach over any other although Scrum is taken as a reference to explain the concept of tailoring.  It can be applied to any type of project and can easily be implemented alongside specialist, industry-specific models.  Demerits of PRINCE2® Agile:  It does not touch upon the various project management tools or techniques which are essential for project management. Merits of PMI-ACP®: It prepares the project managers to become versatile with different types of agile project management practices. Coverage of different types of tools and techniques polishes one’s ability to manage scope, cost, time, quality, risks, resources, stakeholders, communication etc. Demerits of PMI-ACP®: It does not have an exclusive body of knowledge (BOK) like PMBOK® guide. Reference to different literature and books may be essential. This means a structured way to agile project management is missing in its approach.  The best-suited certification: How to pick the right one? PRINCE2® Agile can benefit the existing PRINCE2® community, PRINCE2® Practitioners, anyone who is using agile in Project Management. Even organizations and individuals outside the PRINCE2® community, having experience with agile can benefit from this certification. It is also ideal for total novices. If you fall under any of the categories mentioned above, you can pick this certification as your first step in the project management world. This is also the right choice for professionals and enterprises that serve clients based in UK, Europe and Australia. PMI-ACP is a one-stop solution for project managers and agile teams keen on expanding their skill-set to manage various agile projects. If you are ready to dedicate at least 2 hours every day for 1 to 2 months for exam preparation and earn a globally recognized certification, go for it.  Conclusion: Every practice has its own strength and weakness. Ultimately, it is up to the organizations and practitioners to choose the right project management methodologies to suit their needs and business/career goals.  
Rated 4.0/5 based on 22 customer reviews
5934
PRINCE2®Agile vs PMI-ACP®: What’s Be...

Changing industrial trends and the mass adapta... Read More

"The Escutcheon Workshop" - PART 2 : Kanban Journey for the Infrastructure Operations Support and Service Teams

In my previous post, I had explained what is Kanban and how to view it in the context of Infrastructure Operations Support and Service .  Before we start the implementation of Kanban for a specific Operations Support and Service Team, we need to identify the team composition and work out its team structure. This will help us to implement Kanban effectively for the team. This process is known as team design and it is considered as a part of the organizational design (OD).  When we identify and form a team, we generally identify different support/service skills that the team should possess so that they can undertake the complete support/service for the customer. For e.g. if a single team is expected to provide network support services to the customer, the team should ideally have skills in L0, L1, L2, and L3 support. This ensures end-to-end support for the customer as a single ticket that can be resolved by one team instead of the customer depending on multiple teams (L2 – one team, L3 – another team and other multiple teams, where applicable) to complete his ticket and request. Each member identified at a particular level of support is skilled in their job and the skill level increases as the level move up. Each level has more experience and education. The different service levels are –  L0 – Basic resolution of issues through call resolution. Take the help of knowledge base to manage issue resolution.  L1 – Product Demo and basic troubleshooting including specific call resolution. Deal with physical connections and hardware. Basic network design - from about 30 to about 500 network point design. Basic project management skills.  L2 – Resolution of Technical problems. Focus on medium to large network design. 500 to about 2000 network point design. Intermediate project management skills.   L3 – Resolution of Major problems. Root cause analysis of problems with updations to the knowledge base. Design Experts and Data Center specialists with project management skills. Focus on 2000 to 30000+ network point design and familiar with high-end network equipment (CISCO/JUNIPER/Other Brands). The network support services could be in the form of network design, installation, support and maintenance. Additionally, the levels – L0, L1, L2, and L3 could vary in different organizations depending on the type of services being offered by the organization to the customer and the type of terminology used. We may also have additional or fewer levels depending on the focus of the organization. However, at a broad level, the above classification could be used to categorize different types of operations support and services in an organization. There are two types of team design that can be observed in an organization – teams that are exclusively made up of only one type of skill level, e.g. L2 support, L1 support. This is the component type team design.  Teams that are made up of the complete stack of support services provided – A single team having L0, L1, L2, and L3 skills. This is considered as the feature type team design where like a feature team, the operations support/service team provides complete end to end support to the customer (A feature team is a team that has all the skills needed to support the customer requirements and delivers the features to the customer). As organizations focus on agile and Kanban implementation for their teams and also emphasize imbibing the aspects of Spotify Engineering Culture (a culture that focuses on not having a hierarchical structure and which focuses on host and servant leadership), the attention is on forming teams that have end to end skills to resolve all the customer issues. Hence, the focus on full stack operations support/service teams.  Earlier, a team member used to have specific skills and built his skills in that area only, e.g. L2. This was the T type skill focus. Now, we have the PI type skill focus where a team member is expected to be an expert in at least two areas – e.g. L2, L1 and also have knowledge in other areas. It is acknowledged that there are constraints that need to be overcome to reach this level but it is expected that in the future, the demand will be for full stack skills (L0, L1, L2 and L3) from a single team member. This implies that a team member has all the skills necessary to deliver the service/support to the customer without having to depend on another member or wait to seek help from another member.  There are multiple constraints that need to be overcome in order to reach this state and organizations are facilitating this transformation that may happen over a period of time in the future. This will further strengthen the Operations support / service teams structure and delivery to the customer in the future.  After the skill matrix and the team members are identified to form a team, one of the members of the team is identified as a Kanban Master. He is responsible for facilitating the implementation of the Kanban practices and process for the team along with the help of other non-team members like an Agile Coach, Center of Excellence, Continuous Improvement team and other teams (e.g. training), where applicable.  Generally, we have an initial kick-off workshop for the newly formed team which I call as the Escutcheon workshop. An Escutcheon (as per the Oxford English Dictionary) is defined as –  An emblem or shield bearing a coat of arms or a flat metal piece that is used for protection and also ornamentation around a keyhole, door handle or light switch. The analogy with Escutcheon reminds us of the concept of the team subliminally forming a protective boundary for the team members and which helps the team members to undertake their daily work and take the help of other team members when stuck and ask for help when they are not able to resolve any issue. The team is also having a team name which gives an identity to the team, improves team bonding and which is similar to the coat of arms on a shield that bound fellow kinsmen during the olden times. The output of the workshop is also a diagram in the form of an Escutcheon. Hence, the term Escutcheon. This, of course, implies that the team members exhibit team member characteristics like trust, courage, transparency and other traits so that the concept of a team can be established and sustained in the future. Additionally, this does not mean that the team members can only ask for help from any other member within the team. They are free to also ask for help from any other member in the organization for additional ideas for issue resolution.  A typical output of an Escutcheon Workshop for a Network Operations Support / Service Team is given below -  Are you interested in learning more about Lean manufacturing? April 5th kicks off our Pull / Kanban System and Total Productive Maintenance Workshop! #TPM #PullKanban #Lean Learn more at https://t.co/I0gGUIU4UP pic.twitter.com/c6cfFI7WYx — IMEC (@IMECillinois) March 12, 2018 This network operations team is tasked to support network usage and monitor the performance of the network apart from other routine support / service activities. Hence, this becomes the important tagline or punchline of the team. The key words of the team focus on data, usage and performance (with respect to the network). The team emphasizes collaboration and creativity as key focus areas which will help them in their day to day activities related to network support and service, apart from other focus areas. The team calls themselves as “Network Tigers” and which is ready to support any network issue end to end within their scope of operation pertaining to network support and service. They adopt the logo of a Tiger Face which gives the team an identity to focus, bond and celebrate their successes and wins and support each other during lean periods.  Thus, the Escutcheon workshop helps the team to establish a facade (principal front face) to the customer as a single point of contact to help them for all their issues related to their network and help to resolve them end to end in the shortest possible time and with the highest quality. The team members keep improving their skills to meet this commitment to their customer and learn from their mistakes, adopt continuous learning and implement the lessons learnt from their projects to further strengthen their skills to match and exceed the customer expectations.  Hence, we have now established a full-fledged Operations Support / Service team having all the skill sets that are needed to address the queries, issues and tickets raised by the customer related to their network. Now the team needs to implement, establish, nurture, sustain and institutionalize Kanban values, principles and practices in their team to enable and facilitate the team to enhance customer delight and improve the quality of delivery.  In the upcoming Posts, I will focus on the next step in the Kanban journey as we learn how to implement Kanban for the Infrastructure Operations Support and Service teams – both at the team level and at the scale level (when we integrate multiple teams at scale to deliver support services to the customer).   
Rated 3.0/5 based on 1 customer reviews
"The Escutcheon Workshop" - PART 2 : Kan...

In my previous post, I had explained what is Kanba... Read More

Useful links