Agile Business Analysis (ABA)

Maximizing the Value of Your Product Backlog (Part Two)

Valuating and prioritizing your features

The Product Backlog is the heart of defining any Agile solution.  The requirements that are identified in the Product Backlog drive the priorities that the Agile development team works on, they establish the scope of the delivered solution, and they ultimately determine the business value that the organization will receive from their Agile investment.  This is the second of two articles that provide you with techniques for maximizing the value of the features in your Product Backlog.  The first article, Maximizing the Value of Your Product Backlog (Part One):  Gathering the full scope of req

Maximizing the Value of Your Product Backlog (Part One): Gathering the full scope of requirements

The Product Backlog is the heart of defining any Agile solution.  The requirements that are identified in the Product Backlog drive the priorities that the Agile development team works on, they establish the scope of the delivered solution, and they ultimately determine the business value that the organization will receive from their Agile investment.  The challenge is that most Product Backlogs are based on input from selected stakeholders, rarely representing the full scope of requirements - and constraints - that need to be considered before priorities and business value can be accurately identified.

This is the first of two articles that provide you with techniques for maximizing the value of the requirements in your Product Backlog.  This article focuses on ensuring that you have considered the full scope of potential sources for identifying what the solution needs to deliver - and equally what it should notbe delivering.

Don’t Over Plan! Let the Plan Evolve for an Agile Approach

We all know how to plan.  From waterfall, we know how to over plan.  But how much planning is necessary if you are using an agile approach?  Here’s an idea…try starting the first piece of a project before you have the full plan.  Radical thought?  Did your heart skip a beat?  Here’s why this experiment might change your attitude about planning.

 

How to Be Agile in a Non Agile Organization (Part 2): Aligning Agile projects to corporate reporting structures

This is the second in a series of articles that will give you strategies for aligning your Agile work to your organizational structures.  The first article focused on delivering Agile projects within existing Project, Process and Quality Management frameworks. In this article, the focus is on delivering Agile projects within the existing corporate reporting structures of your organization.

Agile approaches provide a number of mechanisms for tracking progress, including formal reports (e.g. executive dashboards), status update tools (e.g. WIP boards and product backlogs), and ongoing communication with stakeholders.

The ideal Agile reporting environment would leverage these tools without asking staff to do extra (often redundant) work to meet corporate reporting requirements. Specifically, this would involve using:

 

7 Agile Concepts You Can Apply Successfully to IT Areas Other Than Software Development

Agile is an iterative form of software development. Through its rituals and ceremonies, it provides a quicker way to deliver value to the actual customer of the software. Through its focus on prioritization, agile insists that the work most important to the customer be completed first. Through its dedication to team empowerment, agile pushes the “how” to the team level where the team takes ownership of delivery and quality. As agile has proven its value in the software engineering field, it also has many concepts that can prove beneficial to other IT areas. Listed below are some of those concepts and examples of how they might be implemented.

Syndicate content

Shopping cart

View your shopping cart.

Business Process Management Jobs