4squareviews

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

These next two posts deal with the processes related to the fifth knowledge area of Risk Management that are performed in the Planning stage:   5.4 Risk-Adjusted Backlog and 5.5 Regulatory Compliance.

Risk-adjusted backlog was discussed in detail in the last post, but its content dovetails with that of the current process, Regulatory Compliance.

Risk-adjusted backlogs are a risk management practice where features that are prioritized are those that include industry best practice compliance, such as Six Sigma or Lean features, or regulatory compliance features.

Regulatory compliance features have the HIGHEST priority, because if they are not met, the product may not even be allowed into the market.   From the end user’s point of view, that feature may have not any direct perceived value, but it has indirectly an EXTREMELY high perceived value, because it that regulatory compliance feature is not met, there wouldn’t even BE a product on the market for the customer to use.

These features require experts who know about these regulatory compliance features, and so the team may have to reach out to expertise outside of the team or even outside of the company.

But the fact that industry and regulatory compliance issues do NOT effect an individual company has two positive benefits for the company doing the project.   First of all, the compliance issue effects the competition in the exact same way, so it levels the playing field, so to speak.    Secondly, since it effects all of the products in a certain market segment the same way, if a company handles one set of regulatory compliance issues for a product, any subsequent product is going to face similar issues and therefore the learning done on the first project will transfer over to subsequent projects.   You don’t have to re-invent the wheel, in other words.

Knowledge of these regulatory compliance issues will help the development team prioritize those features that are effected by them–they are “must have” features which must be dealt with first.   Then, and only then, can the development team discuss features over which there is at least some degree of freedom.

After taking tomorrow off and discussing another topic, I will return in two days to discuss the next knowledge area of Communication and the processes related to this topic that are done during the planning phase of a project.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

These next two posts deal with the processes related to the fifth knowledge area of Risk Management that are performed in the Planning stage.

The agile framework is affected by the environment in which projects are done, which include the industry framework and the regulatory (governmental) framework.    So risk-related backlogs are a risk management practice where feature priorities are included that include requirements for industry best practice compliance, such as Six Sigma, Lean, etc., OR regulatory requirements.    Although these features may appear to have little direct business value to the customer, NOT having these features would result in sanctions and penalties, which of course would prevent the customer from receiving the benefit of the product in any case.

It is a way of prioritizing work that mitigates or avoids risk associated with nonconformance with these industry or regulatory standards.

The next post is on the process of 5.5 Regulatory Compliance.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

The next block of three processes I am going to describe are those belonging to the “Team Performance” knowledge area (equivalent to the “HR Management” knowledge area in traditional PM) that are done during the Planning phase of the project.

The first process 4.4  Coaching/Facilitation, was described in the first post in the series.  In the last post, I covered 4.5 Collaboration/Negotiation.    This is almost a description of a soft skillset as opposed to a process, although it is most often used during the iteration planning meeting.   In this post, I cover process 4.6 Motivation/Empowerment.

John Stenbeck relates how Alistair Cockburn describes three pride-related factors in his book “Agile Software Development:  The Cooperative Game” that are related to team motivation.

1. Pride in work–team members are intrinsically motivated to deliver a quality product.
2. Pride in accomplishment–the act of winning is a small reward unto itself; 12 small monthly wins are superior to the promise of a large win at the end of the year.
3. Pride in contribution–individual members find more motivation and satisfaction in their team being acknowledged than in receiving an individual award, so they are motivated to achieving team goals.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

The next block of three processes I am going to describe are those belonging to the “Team Performance” knowledge area (equivalent to the “HR Management” knowledge area in traditional PM) that are done during the Planning phase of the project.

The first process 4.4  Coaching/Facilitation, was described in the last post.   In this post, I cover 4.5 Collaboration/Negotiation.    This is almost a description of a soft skillset as opposed to a process, although it is most often used during the iteration planning meeting.

Why are iteration planning meetings so important?   Well, for one, they are the most frequent type of meeting you will have in agile project management, so setting the tone of collaboration and negotiation in these meetings will really set the tone for the entire project.

Also, it is the “front line” for negotiating on scope.   To enter negotiation and aim for a win-win situation should be the goal.

What is the goal of iteration planning?   To choose a group of stories the team can successfully complete within the timeframe of the iteration.

It is not just the number of stories that needs to be agreed upon, but the optimal combination of those stories so that there will be a potentially shippable increment.   And to make sure that this potentially shippable increment meets high quality standards, there needs to be a mutual agreement on a concrete and explicit definition of done.    If this issue is NOT adequately addressed during the iteration planning meeting, then the results of the iteration could be disappointing for the customer/proxy or the team, and the trust factor between the two may be eroded.

Yes, there is a tension between the customer/proxy and the team that is inherent in the fact that one may be pushing for efficiency (i.e., getting as many stories completed as possible), while one may be pushing for effectiveness (getting all the stories given as complete as possible).   But this is a natural tension and it is always important to realize that the two have different perspectives on (hopefully) the same reality and goals.

The next process is 4.6 Motivation/Empowerment, and that is the subject of the next post.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

The next block of three processes I am going to describe are those belonging to the “Team Performance” knowledge area (equivalent to the “HR Management” knowledge area in traditional PM) that are done during the Planning phase of the project.

Why is coaching and facilitation by outside consultants recommended in agile?   For two reasons:   first of all, the team needs to adapt to change rapidly, and having someone who is familiar with the process is helpful.    Secondly, since team members are co-equals, it is often helpful to have an outsider be the one to coax the team towards change, rather than one member of the team trying to do this for the sake of other team members.

There are four environments where formal coaching and facilitation are very important.

1. Implementing eXtreme Programming (XP).   This is a highly disciplined agile framework, and having an experience coach and facilitator is helpful for the team to learn and master practices such as test-driven development.
2. Scaling agile to the enterprise.   When transferring an agile framework from the level of the team to the level of the entire enterprise, an external coach can be helpful in onboarding agile with both teams and management.
3. Conducting large retrospectives.   When the retrospective involves more than one team, or more than one product or even business unit, an external coach can guide how to conduct the meeting to cover such a large area in an effective and meaningful way.
4. Having customers or senior management attend team meetings.   If customers, functional managers, or senior managers ask to attend a daily meeting or a retrospective, and they are new to agile practices, a coach is helpful to make them aware ahead of what the rules are allowable participation so that they do not derail the meeting.

In the next post, I cover process 4.5 Collaboration/Negotiation.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

In the last post, I wrote about affinity estimates, the process that brings the dimensions of priority and sizing to a group of user stories so that a Roadmap can be split up into a series of Releases, and then each Release can be subsequently broken down into Iterations.   This post goes through the step-by-step process of how to do this process.

1. The team gathers and on the top of a whiteboard a scale is written, starting from extra small (XS) to the left to extra large (XL) to the right.
2. A “parking lot” is defined to the side of the space defined above.
3. Each team member is given an equivalent stack of User Stories written on cards.
4. Each team member sizes each story relative to other stories.
5. Each team member places each story on the board, with stories of the same size being placed within the same column.
6.  Stories that are too vague to be sized are placed in the Parking Lot.

That is the first pass.   Here are the steps to the revision phase.

1. Each team member reviews the user stories he or she placed and moves them to a different column if they believe they placed the user story incorrectly in the first pass.
2. The first time a story is moved, a small diagonal line in the bottom right corner of the card.
3. The second time a story is moved, another small diagonal line is placed in the bottom right corner of the card, this time forming an “X”.
4. If a story must be moved a third time, the story is deemed to be too vague and is moved to the parking lot space.

Here are the steps to the final phase.

1. Vague stories that are in the parking lot space are discussed as to what clarification is necessary, such as acceptance criteria, tests to be identified, etc.

The resulting Affinity Board shows all of the stories that are understood to be part of the plan, and shows their relative size of each story.

Then the stories can be ranked in terms of priority so that the user stories in the Roadmap can be grouped into stories that have the same priority, and these can designated as being Release #1, Release #2, etc.

This completes the processes that are involved in Adaptive Planning during the planning phase.   The next post covers the next knowledge area, that of Team Performance.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

Today’s post comes at the end of a block of processes that are in the Adaptive Planning knowledge area (the equivalent of Time and Cost Management in traditional PM), and are done during the Planning process group.

The previous processes dealt with estimation of the size of user stories, that is, the relative amount of effort required by the team to develop them  to fruition.   The process for this post, 3.14 Affinity Estimates, deals with the sizing of a large number of user stories, used when planning on a larger scale such as a Roadmap or Release.

As a reminder, a Roadmap is the equivalent of a program level of plan for a sequence of Releases of the product or service.    How does the “affinity estimate” approach deal with this large number of user stories?   In a nutshell, it uses a large board on which there are two dimensions to be concerned about, the priority and the sizing of the stories.   The stories that have higher priority (the “must have” features rather than the “it would be nice to have” features) get placed at the TOP of the board and the stories with lower priority get placed at the BOTTOM of the board.    This dimension is the “affinity” part of the “affinity estimating” process.   Those stories that have the same affinity in terms of priority will get grouped together for release number 1, release number 2, etc.   This will give the Releases involved in the Roadmap.

For the other, horizontal dimension, those stories that are smaller in size get placed at the LEFT side of the board and the stories that are larger in size get placed on the RIGHT side of the board.   This dimension is the “estimating” part of the “affinity estimating” process, and this will give the relative size of the user stories in any given Release.

This gives the general idea of the process.   For the step-by-step recipe on how to do the process, go to the next post…

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

Today’s post is about an estimating technique called ideal days or sometimes referred to as ideal time.   Actually it’s the start of an estimating technique, which is refined in using actual days or actual time.

What are ideal days?   They are the unit of measure expressing the work time required to complete an activity assuming that there are no interruptions so that work can be completed with 100% efficiency.    Now how realistic is a work day that assumes no interruptions?   Not very.

That’s why the next step in estimating the work time required to complete an activity is actual days.    This is a refinement of the ideal days estimate, but this time with the assumption that typical interruptions will occur and reduce the 100% efficiency rate to a lower rate.

However, as John Stenbeck points out in his book is that even this correction is difficult to estimate.    How does one estimate a “typical interruption”?    How does that typical interruption actually reduce the efficiency?   It’s a greater idea for estimation, but harder to implement than it looks.

This is why the preferred method is to use story points, process 3.12.  Although this seems to be less precise because it is a relative, rather than an absolute, estimating method, it ends up using the collective brainpower of the group to come up with the size of user stories relative to each other, from which a total estimate can be made using the next process, 3.14 Affinity Estimating, which is the subject of the next post.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

The process covered in this post is actually a tool, and that is story points.   Story points are used to quantify the work effort at a high-level by giving an indicator of how much difficulty will be involved with the development of a given user story.

They are used often in conjunction with the process 3.11 Planning Poker (see previous post).  Story points are expressed in terms of numbers in the Fibonacci sequence 1, 2, 3, 5, 8, 13, 21, …, and these are used because they form the basis of many natural forms and the human mind seems predisposed to their use.   The relative size of user stories can be estimated using story points, and their intuitive nature makes them easy to use in the first part of agile estimation.

The next post deals with the concept of actual days, as opposed to ideal days, and their importance in the agile estimation process.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

Today’s post is about the process 3.11 Planning Poker, which is a tool used as part of doing the process 3.8 Sizing.  Sizing is the process of estimating the relative amount of development effort needed to complete a user story.   Planning poker is a tool used to accomplish this.

1. Out of all the user stories, the team chooses a story that represents a midpoint, which could be referred to as a “medium” size user story.   Usually this story is given a value on the Fibonacci scale, typically 5 or 8 story points.
2. Each successive story is shown to the team, together with a brief discussion to clarify what it entails.   Then each member of the team makes an independent vote with a deck of cards that have Fibonacci numbers on them.   So if the user story is about the same difficulty as the first “medium” story, then a person would assign it an “8”, let’s say, if that was the number assigned to the midpoint story mentioned in the paragraph above.   If it is a smaller user story, then each member of the team assigns it a value from 1, 2, 3, or 5; likewise, if it is a larger user story, the team member assigns it a value or 13, 21, or larger.
3. The votes are compared, and the person or persons who gave the lowest score out of the range of numbers given as a a vote has to explain the reason for the outlier estimate; likewise the person or persons with the highest score of the range of numbers must explain their vote as well.
4. A revote is done until a consensus on the size of the story.
5. If there is no consensus reached, then this could be because the story is too vague to be effectively estimated, and it is returned to the customer/proxy for further clarity.
6. If there is a largest value allowed for a user story, say 21, and a consensus is reached that the particular user story is larger than the allowed maximum, then that story is returned to the customer/proxy for further decomposition.

John Stenbeck recommends that the Planning Poker meeting be facilitated by someone outside the team, either an agile coach or a Scrum Master from a different team.

Now the two dimensions of priority and size of a user story are combined in a process 3.12 Affinity Estimates, which is the subject of the next post.

In the next post, I will discuss how the three elements of a cross-functional team, planning poker, and Fibonacci numbers can help reduce three significant risks associated with estimating and sizing (processes 3.8 and 3.9).

Filed under: Uncategorized | Leave a comment »