Archive for the ‘Business Value’ Category

Slicing User Stories, Delivering Value

Friday, February 24th, 2017

Are you on one of the many agile teams struggling with backlogs and user stories? Don’t give up. I teamed up with Jeff Sutherland, CEO of Scrum Inc., to deliver a webinar called “Slicing User Stories”. We focused on helping teams manage their backlogs, improve sprints and release planning, and increase delivered value using practices Mary Gorman and I wrote about in Discover to Deliver.

Here’s a summary of what we discussed. And stay tuned; I’ll go deeper into this in an upcoming webinar with the Scrum Alliance on March 15th. Continue reading

Five Ways a Product Owner Can Build Trust

Thursday, January 26th, 2017

For project teams to work together effectively, team members and stakeholders need trust. Each team member (product managers and owners, leaders, subject matter experts, and technical staff) have different roles and different interests.

As a product owner responsible for defining (and refining) the product backlog, you are expected to juggle a variety of issues including: choosing the most valuable work, meeting deadlines, controlling costs, incorporating bug fixes, addressing technical debt, ensuring quality, and communicating the changes to your users. If that trust breaks down, your product and process will, too. The result may be hidden agendas, rumors, gossip, no shows to standups, whining, or even subversive behavior. Continue reading

Factors for Making Value-Based Product Decisions

Wednesday, December 14th, 2016

Value

Making value-based decisions on what to deliver and when it needs to be delivered is one of the most important responsibilities of product ownership. What exactly is value? Value is fair return in goods, services, money, or some other benefit in exchange for something.

Value is what you get in exchange for what you give. In software development, we tend to identify value in terms of features. They are related to be sure, but quite different. Features as cohesive bundles of functionality that align with business goals and objectives. Features can come in various formats and levels of granularity, including user stories, minimum marketable features, minimum viable product, epics, and so on. Continue reading | 1 Comment

Focus on Value: 4 Factors Every Team Should Consider

Tuesday, June 17th, 2014

1Most of our clients share the same goal: deliver value. Yet often we find that these same clients cannot define what value looks like for their companies, or determine how to use value to inform project decisions.

We’ve identified 4 key factors to help your team bring value into focus:

  • Involve the Right People
  • Define Value Transparently
  • Look Toward the Short Term
  • Have the Vision to Change

Involve the Right People

Defining a product’s desired result, before building it, is fundamental to that product’s success. To do this successfully, you need to identify all of the key stakeholders from the customer, business, and technology realms. These stakeholders need to work together, as collaborating product partners, to envision the product, define goals, and specify measurable objectives, thereby creating a high-level view of the desired product outcomes. Having these key markers will ensure that the team is always building the most valuable thing. Continue reading

Insights and Takeaways: Agile Topics at Project World/World Congress for Business Analysis

Wednesday, October 23rd, 2013

insights
For the past several years, I have had the privilege of chairing the Agile Summit portion of the Project World/World Congress for Business Analysts. I hope you were able to join us last month in Orlando. We had a tremendous turnout and enjoyed our time learning and networking with each other.

Since then, I’ve had several requests for a summary of my half-day tutorial with Ainsley Nies, “An Agile Approach to Project and Products” as well as the Agile Summit presentation “Got Value? A Practical, Sustainable Value Model for Making Agile Product Decisions” and the track session I gave: “It’s the Goal, Not the Role: The Work of Agile Project Management and Business Analysis.” I wrote up a quick synopsis of all three, along with some suggestions that you can try in your next planning or retrospective session. Continue reading | 1 Comment

Rope Your Scope: Reining in Scope Creep (Part II)

Wednesday, June 19th, 2013

Slide1Last time, I told the story of a team that experienced a breakthrough after clarifying the scope of a stalled project. Noting that scope creep—the unrestrained expansion of requirements as the project proceeds—is cited as one of the top project risks, I promised to describe some of the good practices that help product partners manage product scope in a disciplined way. With clients, I always stress the importance of developing a product vision, identifying goals and objectives for the product, and clarifying the product partners’ value considerations very early in the project before development proceeds. Let’s look at ways to do that. Continue reading | 1 Comment

Rope Your Scope: Reining in Scope Creep (Part I)

Thursday, May 9th, 2013

scope creep image 2- contextRecently I worked with a project team developing a software product under grant from four entities, with a government agency as their ultimate customer. They called me in because, three months into a four-month project, they were desperately behind. Why? They’d been spinning in circles, trying to satisfy diverse stakeholders who had overlapping as well as conflicting requirements. The funding was split among several competitors, each with its own competencies, and there was a sense that the government agency was playing favorites based on its own preferences in the domain. Continue reading

Cure Your Agile Planning and Analysis Blues: The Top 9 Pain Points

Tuesday, March 5th, 2013

frazzledproductchampionIf you’re on a team that’s transitioning to lean/agile, have you experienced troubling truths, baffling barriers, and veritable vexations around planning and analysis? We work with many lean/agile teams, and we’ve noted certain recurring planning and analysis pain points.

Mary Gorman and I shared our top observations in a recent webinar. Our hostess, Maureen McVey, IIBA’s Head of Learning and Development, prompted us to begin by sharing why we wrote the book Discover to Deliver: Agile Product Planning and Analysis and then explaining the essential practices you can learn by reading the book. Continue reading | 2 Comments

Software That Matters: A Review of Gojko Adzic’s Impact Mapping

Wednesday, February 6th, 2013

Impact Mapping: Making a Big Impact with Software Products and Projects, by Gojko Adzic, explains how to use an efficient visual modeling technique to ensure that project partners build the right products—or, as the author says, products that have impact. Impact mapping, the subject of this lithe, approachable book, is an adaptation of visual mapping techniques (effect mapping). Continue reading

Using “Given-When-Then” to Discover and Validate Requirements

Sunday, December 9th, 2012

By Mary Gorman and Ellen Gottesdiener

In our book Discover to Deliver: Agile Product Planning and Analysis we discuss the usefulness of the “Given-When-Then” technique to explore (discover) and confirm (validate) product options. Here we summarize the technique*, brainchild of Dan North.

What it Is 

Given-When-Then (GWT) is a structured format for expressing scenarios with example data, including pre- and post-conditions.

Usefulness

GWT helps project stakeholders (business, customer and technology partners) communicate using business domain language. You can use GWT to explore product options and confirm selected options and confirm selected options, in a concrete, tangible way. Often called “specification by example,” GWT provides living documentation for your delivered product. It simultaneously specifies requirements while identifying acceptance tests, thereby streamlining discovery and delivery. Continue reading | 11 Comments