In my prior blog, I shared that the Product Canvas is a tool anchoring a shared understanding of your product. Part 1 of the canvas provides contextual and strategic information. Part 2 summarizes the key compositional element of your product requirements using the 7 Product Dimensions.

Continue reading

What is your product?

If you ask your product development team members, product managers or owners, colleagues in finance, service or operations, marketing, sales, compliance, and all the other departments and teams that make up your organization, would they agree?

It might surprise you to realize that for many organizations, not everyone has clarity around something so fundamental. I’ve developed a Product Canvas to address this issue. The canvas also helps product managers or owners proactively steer their products.

Continue reading

I guess you, like the most of us, have a problem breaking work down to small but still valuable pieces and that your MVP (minimal viable product) is more or less the same as the project scope. If you recognize yourself in this than keep reading.

Continue reading

Agile development with short release cycles have been here for a while now. Most of us want fast feedback loops and many even Continuous Delivery with changes in production software everyday. However, most of us also want secure software and the question is: Can security engineering keep up the pace? A fast feedback that your production website has been hacked is not so nice.

Security is a quality attribute of your software, just like performance. If you don’t want to be surprised by bad performance in production, what do you do? You test and design for it of course and you preferably do so continuously from the start.

In my experience, the same however cannot be said of security. It is very often relegated to a once a year penetration-test activity. Not really an agile way of working is it? Not a secure one either since untested software is released as often as everyday. There must be a better way of working which allows us to both work in an agile way and to verify security on the way.

In the security field people like Gary McGraw have long been advocating ways of “Building Security In”. The Microsoft MVP Troy Hunt also proposes that you should “Hack yourself first”, instead of just waiting for the pentesters. Shouldn’t it be possible to weave these security activities into the process the same way as it is possible with normal testing activities using TDD? Indeed I, as well others believe it is so. Let’s look at how small extensions to an agile process can work in this direction.

Extending Sprint planning to deal with security

To start off you must first know what the requirements are. In a normal agile project this is done by eliciting User Stories from the customer or the Product Owner.

Let’s take an example of an online e-Commerce site. A User Story might be “As a customer I want to be able to add a review of a product so that information about products can be shared between customers”.

This works very well for traditional functional requirements, but for non-functional requirements a little extra thought is needed. In the case of security requirements it is often useful to state a requirement in a scenario that should NOT happen. In our case we shall call these scenarios “Abuser Stories”. These stories are non-technical descriptions of bad things you want to make sure you avoid. An Abuser story for this site might be:

“An attacker uses the Review Product-function to spread malicious Javascript”. Another might be: “An attacker abuses the Review Product-function to gain unlimited access to the database”.
A Product Owner might not be able to come up with these stories himself, but might need the help of a security engineer to help him with finding these threat scenarios.

Continue reading

Today I met a crowd I do not bump in to all that often; project managers. I decided to share insights from Agile projects, stretching from Hospitals to Digitilization, how they simplified and speeded up their pre-studies. Learning how to do so well, helps avoiding the “we have to speed up implementation, to make up

I recently attended a course (the excellent LeanUX course held by my colleague Martin Christensen) and again the topic of what a MVP is or is not came up in a discussion. In the Lean startup-world an MVP is defined as the smallest thing you can make to validate a hypothesis which helps you decide if you should continue developing something or if you should stop. For more information about this, I suggest you read Eric Ries’ blog post on the topic. However, in (very) many companies and organisations the term is used to describe the first version of a product released to the end customers. This “version one release MVP” usually contains as little functionality and features as is possible without making the end customers too upset, disappointed or unwilling to pay.

Another colleague of mine, Henrik Kniberg, wrote a quite thorough and lengthy blog post about MVPs a while back where he touched upon the point I’m about to make. While quite a few people see the different uses of the word MVP as problematic, I see it as a symptom of a need for a better word for describing at least one of its currently used meanings, i.e. the “version one release MVP”. Luckily enough a good friend and coworker gave me the answer to that need a few years ago: He called the first release of the hardware product we were working on at the time the “Minimum Loveable Product”.

Continue reading

You’d think the topic of value would be straightforward when it comes to agile product management and ownership. After all, early and continuous delivery of value is the first principle in the Agile Manifesto and product backlogs need to refined based on value.

And yet, value is not easily defined, qualified, quantified, or agreed upon.

With many smart, experienced folks together at the Agile Product Open last month, I decided it would be informative to propose the topic “Value: The Whats, Whys, and Hows” in the marketplace of ideas.

To start the conversation, I offered my favorite definition, borrowed from the Value Standard: fair return or equivalent, in goods, services, or money, for something exchanged. From there, our conversation grew richer and deeper.

Continue reading

Just back from Hookedfest – a conference for product people. It’s refreshing to see and discuss product development from a market and product perspective, in contrast to the “what can we build” perspective we all to often resort to as engineers. It was interesting to see other speakers (for example the Google guy) share similar experiences on

The key to product success is to discover and deliver the right product for the right customers—and to do it at the right time. That doesn’t change when you move to an agile way of working. In fact, appropriately applying the agile mindset amplifies the imperative of eliciting and specifying the right requirements. The goal is to deliver the highest value product needs (requirements) in as short a time as possible.
Continue reading

Här är mina slides om Agila kontrakt från Devlin 2014. Jag hoppas det skall inspirera fler företag och myndigheter att börja använda sig av dem, då de medför väsentligt lägre risk än traditionella kontrakt. (Använder du Agila kontrakt idag – tveka inte att höra av dig!) Vi har i Sverige dåliga practicies för upphandlingar och

Crisp’s Youtube channel has made a new release – introducing Concepts. Concepts is used to let passionate people run with ideas, a different approach than that of traditional product ownership. If you do use in conjunction with a product owner, it allows that person to spend more time on the field with customers. Ps: The

When is a so-called requirement really required? And is it the “right” requirement? The answers depend on many facets: stakeholders, value, planning horizon, and so on. This article explores using options as a means to identify high-value requirements, at the last responsible moment.

My Requirement May Be Your Option

Product requirements are needs that must be satisfied to achieve a goal, solve a problem, or take advantage of an opportunity. The word “requirement” literally means something that is absolutely, positively, without question, necessary. Product requirements must be defined in sufficient detail for planning and development. But before going to that effort and expense, are you sure they are not only must-haves but also the right and relevant requirements?
Continue reading

One of the key challenges for any organization moving to a Lean flow is learning to slice bigger things to small. If you practice this long enough this becomes second nature and you stop thinking about how you do it.  The good news is this skill can be taught and to show the dimensions available

Our human brain is way better interpreting visual information (images) than any other information. Evolution taught us to survive this way. Yet, still today, the most common form to deliver requirements is … text. In the old waterfall days it meant a lot of text, today using Agile slightly less text, but still, text. If we do it well we back it up with a conversation.

Let’s look at an Agile example, using the “As a..” syntax:

“As a buyer, I would like to buy a pair of shorts, so I can go running.”

Continue reading

Here comes a new post from Ellen Gottesdiener who comes to Stockholm to hold her highly appreciated course Agile Requirements Analysis and Planning for Product Success.

In a recent interview in the New York Times, Panera Bread co-CEO Ronald M. Shaich talks about the importance of de­veloping an organization’s “discovery muscle” as well as its “delivery muscle.” Most companies have worked hard to perfect delivery—how they get work done—he says, because delivery “feels rational, people feel much safer with it, and you can analyze it.” But discovery—the activities you undertake to define or change your product, service, or market—is about “leaps of faith. It’s about trusting yourself. It’s about innova­tion.” The key, Shaich says, is for the discovery muscle to be at least as strong as the delivery muscle.

He took the words right out of our mouths. This need for balance between discovery and delivery applies in spades to software development. Our new book, Discover to Deliver: Agile Product Planning and Analysis, explicitly makes the case for equally balancing your commitment to these key ac­tivities. We define the relationship between them: In lean/agile software development, discovery and delivery are interwoven, interdependent, continuous activities (see figure 1). Each feeds the other.

Continue reading

Ellen Gottesdiener is an internationally recognized leader in the collaborative space where agile requirements + product + project management converge. She coaches, trains, and presents to thousands of people globally and has facilitated hundreds of discovery and planning workshops across diverse industries.
She will hold her popular workshop in Stockholm 25-27 September 2013.

It’s the Goal, Not the Role:The Value of Business Analysis in Scrum

In agile development, what happens to the traditional business analyst? Consider Scrum, currently the most popular agile method. In Scrum, there is no “business analyst” role. In fact, there is not an explicit role for tester, project manager, architect, developer, data administrator, user experience designer, customer support representative, or product trainer. Instead, Scrum has three roles: the product owner, the Scrum Master, and the delivery team. Their collective goal is to deliver high‐valued product needs continually. So, where and how can a business analyst contribute?

Continue reading