Plan, Build, Test, Track - PLAN – Planning for the Agile Enterprise

Valued Contributor.
Valued Contributor.
0 0 2,763

My dad always told me that “if you don’t plan for it, it won’t happen.” This concept instilled in me the value of creating a goal and then establishing a clear path to reach it. The same sentiment can be applied to software development teams. For software development, instead of merely setting an individual goal you must make sure everyone on your team understands what you’re trying to build—and why.  Planning and communication are crucial to the success of your project.

Proper project planning will provide you with the clarity needed in order for your teams to make critical decisions. Before your software development team starts work on a project, it is essential to set a firm foundation. Requirements and User Stories are just that—the building blocks of your application. Studies show that requirements and backlog management improve aspects of organization strategy and operations management by reducing costs, risk and time taken, while improving application quality.

Imagine starting off with a centralized area of focus and control which provides teams with visibility into the work being done in real time and a single source of record to keep every team member informed.  By properly planning, teams will reap the following benefits:

  • In-context collaboration: Provide focus for team members by delivering information in context of their current work items or tasks.
  • Real-time planning: Plans are always kept up-to-date, in real time. The plan does not just reside on one person’s laptop with multiple versions saved.
  • Lifecycle traceability: Broad coverage and linkage of requirements, dev assets, and test plans. It is now possible for anyone on the team to understand the relationship between different aspects of delivery without having to spend time finding the right person to talk to.
  • Development intelligence: Provides teams with transparency to the code level and a holistic view of delivery.
  • Continuous improvement: Enables teams to adapt and optimize their development performance for changing circumstance and requirements.

Every team is planning somehow – do you want to start off on the right foot? Quality application delivery begins with being able to map project progress to goals and milestones. You want the ability to access updated information without relying on error-prone manual data gathering.

In this blog, we will examine how to PLAN your projects in ALM Octane. From integrating agile user stories to waterfall requirements and backlog management, we will show how ALM Octane enables teams to quickly document business needs and map them to supporting artifacts in the software development lifecycle - such as defects or tests.

Micro Focus ALM Octane can be used by a variety of members on your team ranging from a business analyst, product manager, developer, test automation engineer, and VP of Apps. Octane plan workspace.png

Let’s begin with a brief overview of the environment. ALM Octane offers the use of multiple workspaces, with each workspace being an independent development environment. Based on the settings chosen, you can set which users will have access to the work that you have assigned them to. Data is only shared between workspaces based on user role and permission.


Octane backlog module.png

As you Plan your work, you make use of the Requirements Module and the Backlog Module to manage your epics, themes, features, releases, defects, and user stories.



Requirements management is at the heart of any agile project. It is from the Requirements Module that we set the Agile project up for success. To make the process clear, I’m going to walk through the process by utilizing the personas we talked about above.


Explore the potential of requirements management

Octane Bob.pngTo start our journey, let’s start with Bob the business analyst. Bob’s business recently adopted the use of agile software delivery. He is now trying to identify the project’s scope and is trying to achieve a high-level understanding of business goals to help his team understand/estimate the cost and time needs of the project. Bob needs a place where he can easily plan and manage these agile requirements.


Octane User stories.png

Within ALM Octane’s Requirements Module, we host the business definitions and the business case of why we are delivering the product functionality that we have. In this module, the unlimited layers of hierarchy stand out. By design, this allows Bob to create freeform requirements and business definitions, with constraints as to how deep he can dive down. This gives Bob the ability to go deeper than a traditional backlog which has predetermined levels of Epics, features, user stories.


Bob starts by creating high level business definitions in the Author mode. As Bob details the business case as to why he is building out this application, he captures nascent and contextual information that is pertinent to why the team is building out the product backlog. Once the business case is defined, Bob goes into Manage mode and starts getting more tactical.


Octane history of online shopping.png

In the Manage mode, Bob takes the requirement hierarchy that was just planned in the Author mode, to have it mapped to features in the backlog. With business definitions that validate multiple features in the backlog, Bob can now justify why his team is developing and delivering to functionalities in the product, and how they should prioritize work in the backlog.


backlog module.png

From here on, we are ready to have the features deconstructed into user stories, or feed upward toward epics that are defined in the backlog. It is here that we move to the Backlog – where Bob hands off to Pam, his product manager.



In the Backlog module, Pam needs a solution to help her stay organized. For her to start defining epics, features and user stories, Pam needs to be able to manage releases and tests associated to backlog items for a high level of release quality.


Octane advantage mobile.png

Within the Backlog module’s directory tree, Pam can now see the breakdown of Epics, features, and user stories. From this tree structure, she can easily create relationships and their order within the backlog. In particular, she has the ability to create traceability between backlog items irrespective of where they sit in the directory tree.  





Octane Advange backlog.png

Pam can now select an entity, to see everything that is planned in context of that item. As she selects a feature, Pam can see any user stories/defects associated with the specific feature. The tabs provide for easy navigation, with each entity having their own overview or metrics to report out in the context of work planned.



Octane Advantage backlog 2.png

To start on the release management, Pam selects a backlog item (right). We can see multiple releases listed with visibility into the capacity of the releases. This helps us understand how much work is planned or unplanned and specific team’s capacity under each sprint is. This visibility allows Pam to optimize on her sprint planning, updating information in real time that allows Pam to make the quick decisions she needs.


Octane user story.png

As a product manager, Pam will be creating user stories. She needs the ability to give it a unique name, assign it to a release or sprint, and assign story points to the user stories (including epics/features) conceived. These story points are managed as Tasks, and are measured by hours to reflect actual developer effort undertaken. Pam is now able to add tasks as she creates her user stories, to streamline the release planning process. Tasks can be created at any point in time by someone who has been assigned the story or work effort using ALM Octane’s full planning capabilities.


Octance Mice.png


As part of the planning cycle, Pam wants to be able to easily assign the work she has created to a corresponding release. She is able to do so by simply dragging and dropping this user story into the build release – including the flexibility of being able to assign work to a specific sprint or team in real time. In doing so, Pam is able to see the team’s velocity where the remaining capacity is automatically adjusted. This way, Pam can be assured that teams will have the capacity to take on any newly assigned work.


Octane backlog.png

 Pam is now able to report back to her VP of Apps, who will want to see an overall project reporting. ALM Octane offers visibility to the entire workspace with a separate dashboard in the Backlog module. All of the charts and graphs are actionable, you can click on them for metrics that can be further filtered and drilled down to the desired level of detail for each of the entities. Everything is actionable, measureable, and dynamic. Users like Pam can easily navigate and assess the information that matters.

In this blog, we see that ALM Octane covers all of the needs of agile planning teams as they plan for application project work. We also covered specific roles that a business analyst and product manager play in the process. We were able to create high-level business definitions in the requirements module, and detail user stories, tasks, and release planning in the Backlog. Now that we have planned backlog work, be on the lookout for next month’s blog where we will be creating and monitoring quality in the application releases, an learning how we create test coverage around your work.


About the Author
Zoe is part of the ADM Product Team with expertise in Agile Methodology. She is theTechnical Marketing Manager for ALM Octane and is a Certified Scrum Master.
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.