Thursday, July 10, 2014

How to go from napkin to development — Ideating the Product Backlog

The Situation

So you have identified the business problem and at a high level you’ve defined an approach for solving the issue. You have the idea – how do you turn it into a solution? How do you turn that idea/solution into a product which has a life and a vision which can support changing as your business changes? How do you execute your vision for the product through the agile project management framework? Where do you start?

This is the most common situation thought leaders face when acting as product owners/intrepreneurs for their organization – how do you define the initial Product Backlog for the potential project?

The process of generating, developing, and communicating a new idea is referred to as ideation.


Recently I worked with a Client seeking to replace an antiquated data mining software tool which had been in place for 10 years without any maintenance, updates, or even an assigned technical resource. The tool had hobbled along maintaining usefulness, but falling behind in performance and features. Finally the time had come to determine if the data that the tool mined was useful to the business and if the tool should be reengineered. Management was pushing hard to understand the business value of the data being mined to determine if pursuit of moving forward with tool selection was worthwhile, or if the business should abandon it all together.

As an Enterprise Business Analysis (BABOK v2.0, Chapter 5, p81) project, your ideation should include the following activities:
  •  Define Business Need
  • Assess Capability Gaps
  • Define Solution Scope
  •  Determine Solution Approach
  • Define Business Case

Define the Business Need

You will need to first define the business need, which is the problem to be solved or opportunity available to your organization. During our engagement, the Product Owner surveyed the organization to understand the businesses perception of how the mined data led to business objectives and tasks. I then assisted the Product Owner, conducting qualitative interviews with key stakeholders and thought leaders. The goal of the survey was to determine the value of the mined data to each stakeholder’s role and their perception of the value that this data had to other business areas. The overall objective is to get others to tell you that the resolution of your situation is crucial to the business and not just to you alone.

After you’ve collected all of your research information, you will want to sort things out. I used a thematic analysis approach for synthesizing, to emphasize and record patterns found within the data. We interpreted various topics from the thematic analysis of both the interviews and the responses to the open ended questions used in the survey.

The final step to defining the business need is to validate your findings and your assumptions with the business. I facilitated a brainstorming session with our Client’s key stakeholders, thought leaders, and expanded functional managers using the thematic topics identified via the team idea mapping approach. The session was framed by disclosing the results of the survey and qualitative interviews and reviewing the dominant themes. Individual ideas of similar context from the session were combined and consolidated. The group then prioritized the ideas ultimately identifying the epics for the forthcoming solution.

Brainstorming Session



Assess Capability Gaps
Using the Client’s existing ten-year strategic plan, I conducted a capability mapping of the Client’s defined tactical activities to accomplish identified strategic objectives and create a model associating the business capabilities, processes, and functions with a factor that the data being evaluated supports towards enabling them. This capability mapping allowed me to model the most stable elements of the business and associate a value by which the mined data contributed to the accomplishment of business objectives. I then performed a value chain analysis to understand the sequence of activities the Client performed and how the data in question sustained the development of final service offerings.

Value Chain Analysis

Strategic Alignment


Not all organizations have a well-documented strategic plan, so you will need to identify the measure you will use to align your business need to the overall objectives of your organization.

Determine Solution Scope

Now that you have a good understanding of the business problem, the need of the organization, and the business value your solution contributes towards the accomplishment of business objectives, you need to define just how much of the problem you want to actually fix. It may be tempting, but you should not try to solution for the entire problem all at once. It provides more benefit to your organization if you solution for the highest impact items first and then proceed with fixing the remaining aspects over time.

Using the interview notes and ideas generated from the brainstorming session, I identified the new capabilities required to meet the business needs. We accomplished this task by documenting the high-level requirements elicited during the qualitative interviews and the facilitated brainstorming. These requirements were then aligned to the epics defined during the brainstorming session and further categorized into functional groupings, resulting into an initial product backlog. The product backlog was entered into the organization’s requirements management tool, capturing all of the features and functions necessary to characterize the product which are critical to the solution success.

  

Determine Solution Approach

The project team posited three solution options with Rough Order of Magnitude Estimates for each:
  • Option 1 – Buy a New System – from commercially available options

















  • Option 2 – Leverage an Existing Platform – using an existing technology stack which the organization has great familiarity to create a custom tool


















  • Option 3 – Leverage an Existing Product – expanding the use of a product solution already implemented to include managing the data in question






Define the Business Case
The final step in the process is documenting the reasoning for initiating the project. Our deliverable outlined the:

  • Business problem with supporting background,
  • Assessment of business value,
  • Risks, and
  • Critical success factors for the project, and
  • High Level Business Requirements



You have finalized your case for persuading management to take action. You will need to present the ideas and associated findings to the key stakeholders and decision makers. Working along with the Product Owner, I presented the findings to the organization’s leadership demonstrating the business value in a pitch to secure funding for the project.

Your organization may have a PMO or other formal project governance entity in place. Once your project is approved, the final Business Case can be leveraged to create any Project Charter documentation as well as any other PMO required Project Initiation deliverables. Regardless of the Solution Approach, once your project receives funding, as the Product Owner, you now have the initial Product Backlog which will support all Pre-Game Scrum Activities.

– And you are on your way to the start of a successful Agile project!


Good luck!

The Agile PMLC (Project Management Life Cycle)

Many companies readily admit that the concept of Agile development for software projects fits into their desires to react quickly to changing market forces and their desires to improve speed to market for many corporate initiatives. As competition is a key driver in business, lots of companies attempt to make the switch to Agile to achieve, in some cases, a sustainable competitive advantage, and in other cases to just keep pace with opponents to forego losing market share.

Despite the support from senior leadership, and the assigned resources to be successful, many organizations are experiencing difficulty adapting to an Agile framework. A common challenge businesses face involves actually incorporating Agile projects into an already existing and highly structured Project Management Life Cycle (PMLC). The concept of Agile is a mental shift and is often perceived as minimally documented just-in-time software development and thought to lack the structure of traditional waterfall projects. Many Agile projects are run outside of the PMLC because they do not map to it as easily as do waterfall projects. However, I argue that the Agile framework fits into the PMLC overlapping both the Project Planning and Project Execution phases.

I had a client that has a PMGO (Project Management Governance Office) in place which provides structure for how projects should be run, emphasizing a PMLC for projects to follow. This structure does not readily accommodate for Agile projects; however, as a Scrum Master, I implemented a blended approach to fit my Agile project into their predominately waterfall processes.

Project Initiation is project initiation. All projects, whether business process reengineering, traditional waterfall software development, or Agile software development, should produce documents which satisfy the initiation phase of the project. This includes the Project Charter, Work Breakdown Structure, Risk Analysis, Communication Plan, and Stakeholder Analysis. The Communication Plan for my project included descriptions of all of the Agile ceremonies necessary for running the project: Product Backlog Development, Backlog Grooming, Backlog Release Planning, Sprint Pre-Planning, Sprint Planning, Daily Stand-up, Sprint Demo, Sprint Review, and the Sprint Retrospective. The Project Initiation phase should also capture all of Scrum Team’s methodology for Estimating stories, A Themed View of the Product Backlog (which serves as the Work Breakdown Structure), and a timeline outlining the weekly activities for each Sprint.

Project Planning for an Agile project is composed of the specific Release Plans for the project, laying out the forecasted stories for each Release. The forecasted Stories are identified based on the projected velocity for the Scrum Team. The velocity is determined according to the number of Developers and Quality Assurance Analysts assigned to the team and the time box allocated to the Sprint. Other Agile activities in this phase include Sprint Pre-Planning and Sprint Planning which tightly align to Detailed Planning in the PMLC. Project Execution for my Agile projects is an iterative phase which is repeated with each Sprint. The Monitoring and Controlling during my Agile project is done through several activities: Daily Stand-up, Weekly Status Reports, and through the Sprint Demo, Sprint Review, Sprint Retrospective, and Burn-up Chart which are all conducted at the end of the Sprint.

During the Project Execution phase, I use the Weekly Status Report as the artifact to manage the project issue log, log all project risks, track resource utilization, track costs, and to report any changes in the technical direction of the project. Lastly although Sprints are iterative forecasts of proposed work efforts, Schedule Variances can be reported at the Sprint level by measuring the Team Velocity against the actual Story Points accomplished during the Sprint.

Change Management is interwoven into the framework of an Agile project. At the end of each Sprint, the Team participates in a Sprint Review. During this ceremony, the existing technical direction of the project is evaluated against the learnings the Team accumulated during the Sprint. As a Team a decision is made whether to modify the technical approach or to remain on track with the existing direction. As it relates to the scope of work effort for each Sprint, the Product Owner simply prioritizes the Product Backlog with the User Stories that are most important for the project. Sprint Pre-planning Meetings are when the Team reviews the newly prioritized User Stories and discusses the impact to the existing technical direction. Ultimately, any features which are deprioritized below the agreed to Product Release milestone will move into another iteration unless additional resources or time are added to the project. With change being addressed in this manner, the need for formal Change Management processes becomes reduced. However, it is wise to document shifts in direction to capture the decisions made by the Team during the project.

Lastly, it is my experience that Project Closure for Agile projects do not typically deviate from the PMLC standards defined by the PMO/PMGO. Lessons learned from the individual Sprint Retrospectives should be aggregated into a single artifact. Furthermore, any formal sign-offs from the Product Owner to signify that the individual milestones occurring during the project were satisfied should also be combined into an artifact. I also recommend that a larger scale Retrospective be conducted as a helpful way to capture improvements for the Agile process for new projects within the organization.

Figure 1 below depicts how an Agile framework overlays the PMLC.




By overlaying the Agile Ceremonies into the PMLC, the Scrum Master/Project Manager is able to effectively adhere to the existing organizational PMLC structure, thus meeting Project Management Office (PMO) standards. The only real difference is the location of the documented information and the name of the artifact. The addition of the Agile artifacts to the PMLC will aid the organization’s ability to learn as the number of Agile projects increase; moreover, the move to Agile would not eliminate the level of documented communication typical of most waterfall projects. 

This lens for viewing the Agile framework through the context of the PMLC should now equip you to gain greater traction as you implement your Agile PMLC. Good Luck!