Agile PM Process Grid–2.5 Planning Activities


John Stenbeck in his book “PMI-ACP Exam Prep PLUS Desk Reference”, he creates an agile project management process grid with 87 processes divided into 5 process groups and 7 knowledge areas.

The block of processes I am covering now are those in the Planning process group and the “Value-Driven Delivery” knowledge area.   The first process is the creation of Release and Iteration Plans, and the second process is the one covered in this post, 2.5 Planning Activities.

John Stenbeck lists 5 planning activities that can be used to get teams to work together to generate new ideas.

1. Brainstorming

This is used to generate a large number of ideas which are later whittled down to a smaller set after being analyzed through a set of criteria.    The most important thing to remember is that the brainstorming activity and the filtering activity need to be done separately, because they involved two different modes of thinking, open mode vs. closed mode.

Open mode thinking is about generating ideas creatively by turning off the critical voices which say “oh, that’s no good”, or “oh, that won’t work.”

Many typical approaches to brainstorming are:

  1. Free-for-all, where participants randomly call out any idea that crosses their mind
  2. Silent idea generation, where participants write down silently their individual ideas, which are then shared with the group
  3. Round-robin, where participants call out an idea one by one in a circle (as opposed to randomly as in the free-for-all)

2. Ishikawa (fishbone) diagrams

This is used for identifying potential causes of errors or defects, or the potential source of problems.   The problem to be addressed goes at the “head” of the fishbone diagram, and the “spines” along the fish skeleton represent the primary categories of causes, and the bones along each spine represent specific potential causes or symptoms of the problem that belong to each category.

3. Force field analysis

Force field analysis was developed in the 1940s by an American social psychologist named Kurt Lewin.  But the more I read about the technique, it reminded me of a technique Ben Franklin described in his autobiography whenever it came time to make a tough decision.  He described it as follows:

.. my Way is, to divide half a Sheet of Paper by a Line into two Columns, writing over the one Pro, and over the other Con. Then during three or four Days Consideration I put down under the different Heads short Hints of the different Motives that at different Times occur to me for or against the Measure. When I have thus got them all together in one View, I endeavour to estimate their respective Weights; and where I find two, one on each side, that seem equal, I strike them both out: If I find a Reason pro equal to some two Reasons con, I strike out the three. If I judge some two Reasons con equal to some three Reasons pro, I strike out the five; and thus proceeding I find at length where the Ballance lies; and if after a Day or two of farther Consideration nothing new that is of Importance occurs on either side, I come to a Determination accordingly.

The issue or problem is listed at the top of the diagram, and then the desired state or solution to the issue or problem is listed underneath it.  Then those factors which would drive the team towards a solution are listed on one side, whereas those factors which would restrain the team from that solution are listed on the other.   Those factors which the team is able to influence, either to enhance the driving forces or reduce the inhibiting forces, are listed and plans made for the team to implement them.

4.  Prioritize with dots

When there is a backlog and a decision must be made which items need to be done first and which need to be dropped altogether, a good exercise to do is to prioritize with dots.

Each participant is given a supply of dots and instructions on how to allocate them.   For example, the procedure could be that if you give everyone 10 dots, and instructions that if they give an item 4 dots, then that item should get top priority.   3 dots means second highest priority, and so on.   Everybody goes to the list and makes his or her vote on which items have the top four levels of priority.

If clear winners emerge, then the group proceeds with processing those items that got the top votes for priority.   If there is not a clear winner, then a secondary round of voting may be needed.    But in the end, a priority will emerge that is agreed upon by the group democratically by virtue of this process.

5.  Learning Matrix

This is used in retrospective meetings to generate lessons learned.   Here a diagram with four quadrants is drawn up with each quadrant representing a different theme such as:

  • What went well
  • What to improve
  • What to find out
  • Who to thank

That is just one scheme; others are possible.   After everyone in the meeting understands the heading of each of the quadrants, the team adds ideas under each category with sticky notes until the flow of ideas slows down or the time limit for the exercise is reached.   Like the Ishikawa diagram, this is way to generate ideas that have a pre-set structure to them.

These are just some of the ideas for team meetings, but again I want to emphasize that it must be done in the spirit of the open mode of communication.   For an entertaining demonstration of what this open mode of communication requires, look up the video by John Cleese on YouTube entitled “John Cleese on Creativity”

The next post will cover the next process 2.6 decomposition.

Agile PM Process Grid–Types of Iterations


John Stenbeck in his book “PMI-ACP Exam Prep PLUS Desk Reference”, he creates an agile project management process grid with 87 processes divided into 5 process groups and 7 knowledge areas.

The block of processes I am covering now are those in the Planning process group and the “Value-Driven Delivery” knowledge area.   The first process is the creation of Release and Iteration Plans, and the second part of the process, creating Iteration Plans.   This post goes into the fact that not all iterations are created equal.

Standard Iteration

This is a single cycle of development with a fixed length that delivers new development work that has been subject to quality assurance and user acceptance testing.

Sometimes the standard iterations are preceded by a planning iteration called Iteration 0 (zero).

Iteration 0

This is use to perform foundational work for the project and usually lasts only one week.    This foundational work could include logistics, high-level analysis of options, and communicating with other departments or vendors.

Hardening Iteration

This is the iteration that is performed before the product is released and is used to complete all final acceptance testing.

Handoff Iteration

This is the iteration are used when formal or regulatory documentation must be prepared, particularly when deliverables are being submitted to an external agency such as OSHA or the FDA.

QA/Testing Iteration

This is an iteration that focuses on QA and testing (as the name implies) if these procedures cannot be done during the standard iterations.

Defect Repair Iteration

These iterations focus on fixing defects and bugs before new development work can continue.

Hybrid Iteration

These are standard iterations that reserve a percentage of development capacity for non-developmental work, such as bug fixing.   Such an iteration should be the exception to the rule, and used for unplanned emergencies.

In the next post, I will cover the next process in the process grid, 2.5 Planning Activities.

 

Agile PM Process Grid–2.4 Iteration Plans


John Stenbeck in his book “PMI-ACP Exam Prep PLUS Desk Reference”, he creates an agile project management process grid with 87 processes divided into 5 process groups and 7 knowledge areas.

The block of processes I am covering now are those in the Planning process group and the “Value-Driven Delivery” knowledge area.   The first process is the creation of Release and Iteration Plans, and this post covers the second part of the process, creating Iteration Plans.

Recap

Okay, here’s the process flow so far.   In process 1.5, the Product Roadmap (equivalent to a program in traditional PM) is defined.   The central feature list on that roadmap is created, and then the release plan (equivalent to a project in traditional PM) is outlined.    Once the team velocity is estimated (the amount of work in terms of user stories that can be reliably done during a single iteration), the estimate of the number of iterations is done.

Iteration

The purpose of iteration planning is to identify a highly probable path for completing the required tasks within the duration of the iteration.

The first step in this process is that the duration of the iteration is determined–this can be typically as two, three, or four weeks.

Then there is a soft commitment by the team to what user stories are proposed to be completed during a given iteration.   After a comprehensive analysis of this initial commitment, the team then goes on to a hard commitment.    This is where the team builds confidence in being able to succeed.

This comprehensive analysis includes the following:

  • decomposition of the user stories into tasks
  • decision of who on the team will handle which tasks
  • assessment of availability of team members to handle tasks
  • clarification of how the work will fulfill the acceptance criteria

These steps create the confidence that the team will be able to succeed in completing the work set forth in the iteration.

The next post discusses some of the types of iterations that can exist.

 

 

 

Agile PM Process Grid–2.4 Release Plans


John Stenbeck in his book “PMI-ACP Exam Prep PLUS Desk Reference”, he creates an agile project management process grid with 87 processes divided into 5 process groups and 7 knowledge areas.

The block of processes I am covering now are those in the Planning process group and the “Value-Driven Delivery” knowledge area.   The first process is the creation of Release and Iteration Plans, and this post covers the first part of the process, creating Release Plans.

Release Plan

Just a little terminology first–the program level in traditional PM corresponds to the product roadmap, the project level in traditional PM corresponds to the release plan, and the iteration one step forward in any particular release plan.

So after the product roadmap has been established in process 1.5, and the central feature list created (see last post for details), you can then start on process 2.4 Release Plans.   A release plan generally corresponds to the point at which deliverables can be used or implemented by customers.

The key to effective release planning is estimating the team velocity, which is a measure of how many user stories on average the team can complete in one iteration.    So if the scope is well-defined (i.e., the number of user stories can be accurately estimated), and the team velocity is predictable, then calculating the number of iterations it will take to complete the project is pretty straightforward.

However, during the early part of the project, it may take a couple of iterations for the velocity to stabilize, but there should be a point at which the team velocity is a reliable metric.

Two Key Variables

Having a release plan broken down into iterations allows the team to optimize two key variables:

  1. Delivering customer value as rapidly and completely as possible.
  2. Getting the product to the customer, and thereby to the market, quickly.

The next post will talk about the next part of this process, planning iteration plans from the release plans.   The post after that will discuss the various types of iterations.

Agile PM Process Grid–Central Feature List


John Stenbeck in his book “PMI-ACP Exam Prep PLUS Desk Reference”, he creates an agile project management process grid with 87 processes divided into 5 process groups and 7 knowledge areas.

The block of processes I am covering now are those in the Planning process group and the “Value-Driven Delivery” knowledge area.   The first process is the creation of Release and Iteration Plans, but before these plans are created, the agile team needs to construct a central feature list.

Product features may come from a number of sources, such as

  • end users
  • functional business units
  • internal and external stakeholders
  • requests for proposals (RFPs)
  • development team members
  • senior management
  • competitors
  • government regulations

In creating the list, the project team needs to create some boundaries regarding what is allowed to be on the list, so features that are impossible or are described in an overly vague way are not allowed to appear.

A central feature list may be considered as a “superset” of features to be used for planning the release and first iteration.   It represents what a product could  become over several releases.    It is not written in stone; rather, it is a living document which is dynamic and evolves from iteration to iteration.

If, for example, new features are identified after the first iteration, then the additional critical features identified by the customer/proxy are folded into the evolving release plan.

The process of creating Release and Iteration Plans will be divided into the next two posts to discuss the Release Plans first and then the Iteration Plans.

Agile PM Process Grid–Process 1.7 Prioritizing Stories


John Stenbeck, in his book ‘PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, has created an agile project management process grid that takes the 87 processes he has defined into 5 process groups and 7 knowledge areas.

I am currently covering those three processes that fall within the Planning process group and the External Stakeholder Engagement knowledge area.   The first process in this block of processes is 1.5 Product Roadmap, the second process is 1.6 Minimal Marketable Features (MMF), and the third process is 1.7 Prioritizing Stories.

All of these processes are linked together in the following way.   In the first process 1.5 Product Roadmap, the stakeholders were engaged in the process of setting up the product roadmap and its relationship to the various releases of the product.   In the second process 1.6 Minimal Marketable Features (MMF), the development of the product is refined even further, down to the level of Minimal Marketable Features (MMF), which might be considered the equivalent of minor deliverables in traditional PM.

At this point, you have the scope of the project worked down to a granular enough level that you can the concept of team velocity to make a rough order of estimate regarding whether you can finish the project within the time constraint allowed.   Team velocity refers to the production capacity of the team.

So if you find through process 1.5 and 1.6 that there are 500 story points involved in the particular release you are working on, and the mean team velocity turns out to be 50 story points per iteration, then you can say within a rough order of magnitude that the release will take 500/50 = 10 iterations to complete.

However, if this is a project where the time constraint is fixed, and you only have, say, 7 iterations worth of time, then you have figure out how to make do with features that add up to 350 story points rather than 500 story points.

This is where this process 1.7 Prioritizing Stories comes in.   What are the

  • must have
  • should have
  • would be nice to have
  • could have

features of the product.   Here the customer/proxy must weigh in the discussion by deciding what it is the product will do, how it will look, and how it will perform.   Based on these criteria, the backlog of features can be prioritized.   It is essential to get the stakeholders’ cooperation in this process, which again is why this is under the “External Stakeholders Engagement” knowledge area.

The prioritization process is sometimes referred to as “grooming” the backlog, and this is because, like the periodic grooming of a pet whose hair is constantly growing, the process started here in the initiating process group continues during the course of the project, where changes in the priority of stories may end up changing between iterations.

The process of prioritizing stories is a significant investment in time on a project, but it delivers valuable returns in offering a path to success.

This concludes our discussion of the planning processes related to External Stakeholder Engagement.   The next block of 4 planning processes are those related to the “Value-Driven Delivery” knowledge area.

Agile PM Process Grid–Process 1.6 Minimal Marketable Features


John Stenbeck created an Agile Project Management Process Grid in his book “PMI-ACP Exam Prep”, which divided the 87 processes he named into 5 process groups and 7 knowledge areas.

I am currently covering those processes in the Planning process group and the External Stakeholder Engagement knowledge area.   The first process in this block of processes is 1.5 Product Roadmap, the second process, 1.6 Minimal Marketable Features (MMF), is the subject of this post.

In the last process, the stakeholders were engaged in the process of setting up the product roadmap and its relationship to the various releases of the product.   In this process, the development of the product is refined even further, down to the level of Minimal Marketable Features (MMF), which might be considered the equivalent of work packages in traditional PM.

However, the difference here is that MMF comprise the smallest set of functionality that provides satisfactory customer value.   Just to take an example, the version of the software for a cellphone might be called 1.2.4, where 1 is the large-scale version of the product as designated in the product roadmap, 2 is the second release of that product version, and 4 is the 4th MMF that is being developed within that second release.   So it all fits together like Russian matrioshka dolls.

Defining and then sizing the MMF is important, because this will enable the team to use a calculation to determine the probability of meeting any given release date.   This is a “team velocity” calculation, and is done by taking the number of story points for any given feature, and then taking the mean value for the team’s productivity during a given iteration.   So 500 story points divided by 50 story points (on average) per iteration means that the project will most likely take 500/50 = 10 weeks.

If the resulting schedule estimate ends up being too long for the customer, then the process of reassessing the MMF needs to take place, so features can be prioritized and then lower-priority features can be modified or eliminated.

That process 1.7 Prioritization is the subject of the next post.

 

 

Agile Project Management Process Grid–Process 1.6 Product Roadmap


John Stenbeck created an Agile Project Management Process Grid in his book “PMI-ACP Exam Prep”, which divided the 87 processes he named into 5 process groups and 7 knowledge areas.

I am currently covering those processes in the Planning process group and the External Stakeholder Engagement knowledge area.   The first process in this block of processes is 1.6 Product Roadmap.

Product Roadmap

Why is the product roadmap related to “External Stakeholder Engagement”?   Because stakeholders who are taking their vision and enlisting your company to help make it a reality need to be on board with the process of designing a product roadmap.

What is a product roadmap?   In the world of traditional Project Management, it would be what features the product would entail, sometimes called the product backlog.   For example, the application Duolingo is an app that is used to teach foreign languages for free.    The creation of the app itself would be an example of a product roadmap.   Each language on Duolingo consists of the same features.  The emergence of a course on a new language on the Duolingo app would be an example of a release.   For example, Duolingo has just released for English speakers the 15th language, namely, Polish.    Other languages–Spanish, French, German, Italian Portuguese, Dutch, Danish, Irish, Swedish, Turkish, Norwegian, Ukrainian, Esperanto, and Russian–are examples of earlier releases on that application.   And the release of a new language is itself composed of a series of phases which in an agile project would be handled in iterations.

So the progression from large to small is product roadmap, then release, then an iteration.   Why is this mapping of the releases onto the product roadmap, in other words, the release plan, such a critical process?    Because is how you can use estimating techniques to show a predictable schedule for the delivery of an individual feature or of an entire release from the product roadmap.

In an agile project where it must be completed by a certain date, the release date is defined in advance, but the specific features of the release are negotiable.   Given the team velocity, that is, how many user stories can be processes in any given iteration, you can calculate how many iterations it will take to complete entire set of user stories.

This gives the stakeholder a degree of confidence that the project will be completed on time.   And that is why the stakeholder must be engaged starting at the top level of plans, namely, the product roadmap.

The next process is 1.7 Identifying Minimal Marketable Features (MMF), which is covered in the next post.

Agile Project Management–Planning Process Group


At the end of the second chapter of John Stenbeck’s book “PMI-ACP  and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “Agile Project Management Process Grid”, divided into five process groups and seven knowledge areas.

Chapter 3 covers the Initiating Process Group, and that is the group of processes I have been covering for the past two months.   Now, we are going into the heart of agile project planning, and the book requires three whole chapters 4 through 6 to cover all of this material.

So let’s start with an overview of the process group in general.

First, despite the term “agile,” planning is just as complex and time-consuming as in traditional project management.   And, like in the case of traditional project management, successful agile planning at the beginning of the project is the key to creating customer satisfaction at the end of the project.

Characteristics of Agile Planning

Here are some of the basics of agile planning:

  1. Product feature prioritization–only product features with the highest priority for the customer/proxy have to be planned in detail before initiating the project
  2. Short iterations–these deliver valuable features sooner so that the customer/proxy can interact with a tangible or intangible yet functional product.
  3. Customer flexibility–ensured through re-prioritizing product backlog between iterations.
  4. Team stability–ensured by not allowing changes to the iteration backlog during the iteration.
Organic vs. Overt Practices
Organic practices are defined as those that are inherently part of the agile framework.   Overt practices (aka interventions) are externally imposed upon the agile framework    Agile planning can benefit from both organic and overt practices.
Agile Planning Levels
Here are the agile planning levels, from highest (longest time horizons) to lowest (shortest time horizons), where each level is decomposed from the level of above it.
  1. Market portfolios–longest time horizons and broadest descriptions of the product
  2. Product functionality (aka Themes)–delivered in successive linked waves
  3. Roadmaps–functionality is operationalized in Epics and further defined in Feature Stories.
  4. Releases (User Stories)–in each iteration, user stories are defined that aline with the Feature Stories and can be integrated into product functionality.

The next post will start with the first of the processes in the Planning process group that belong to the “External Stakeholders Engagement” knowledge area, namely Process 1.5 Product Roadmap.

 

Agile Project Management Process Grid–Process 7.1 Define Agile Ceremonies


In his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference,” John Stenbeck has created an “Agile PM Process Grid” which contains 87 processes used in agile project management divided up into 5 process areas and 7 knowledge areas.

I’m now covering all the processes in the first process group called Initiate, and have covered all the processes in that group under the first 6 knowledge areas.   Now I’m moving on to the one process in the seventh and last knowledge, that of Continuous Improvement, called Process 7.1 Define Required Ceremonies.

What do ceremonies have to do with continuous improvement?    These ceremonies referred to are:

  • Sprint Planning, which looks forward to the next iteration
  • Spring Review/Retrospective, which looks backward upon the previous iteration
  • Daily Meeting, which looks at the status of the current iteration

These three ceremonies are formalized in order to engage stakeholders in structured discussions that help clarify and articulate their values and priorities.

By defining these ceremonies, the stage is set for continuous improvement during the course of the project.   But like the “ground rules” of team interactions, the defining of team ceremonies help set expectations and reduce the probability of misunderstandings so that the team can cooperate in producing an actionable, high-value product backlog that is “burned down” or completed incrementally with each iteration.

This covers the last of the processes in the Initiate process group.   The next group of processes is the Plan process group, an introduction to which is contained in the next post.