Dive into the Product Model’s key insights (focus on outcomes), and core idea (the empowered engineer) to re-invent your teams to become Empowered Teams.

The following is an excerpt from the recently released book by Martin Christensen and me titled Holistic Product Discovery. It’s been a 3-year journey that started with a 20-page draft. Numerous iterations later, here we are. Thank you to the fantastic community of readers for your invaluable feedback. Let’s begin. A story about a product

I see many versions of product roadmaps in my work. Unfortunately very few pass this agility test. Does your product roadmap pass the Product Roadmap Agility checklist?

Download the checklist here.

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

Racing is essentially product development on steroids. For a number of years I’ve been following the development of a promising young racing driver – Linus Lundqvist.  Anyone with a little bit of knowledge about racing,knows that there are many components that need to work together, in order to forge success.  Talant – yes. Resources –

So you have a LARGE backlog and you have decided that you need to estimate it.

Not on board? Still undecided? Go read my previous post on the tradeoffs between estimating and not estimating large backlogs.

Still reading? Ok, let’s get to it!

You can do larger scale estimation in MANY ways. What I will share with you here is just one way I have found to do it effectively, with enough accuracy at a reasonable cost. It requires some pre-conditions, such as having a team with an established way of working and some way of estimating on the team level, so it may not fit your situation. But if it does it is probably worth your time to check out.

Continue reading

Estimation seems to have gotten a bit of a bad reputation lately.

One misconception I sometimes see is that estimation beyond just a few weeks is “not agile”. Another trend is that some people advocate against doing estimation at all mostly because they view it as a beginner tool, so by not estimating we are no longer beginners.

To me doing estimation or not does not really say much about “how agile you are”. The way I look at it is that we should estimate when the reasons to do so outweigh the reasons not to do so. That simple.

In some scenarios this also includes doing estimation of large backlogs.

So in this article I want to share what I see as some of the reasons FOR and AGAINST doing estimation of a larger backlog. You can then decide for yourself if your situation justifies doing it or not.

Continue reading

As a product owner, your job is to make assumptions, or hypotheses. (Hypothesis-driven product discovery, anyone?) You assume that your priorities will be the best outcome, the shortest time to market or something else. But how good are your assumption when it comes to reality? Did that sale increase occur and was it thanks to your great mind or just pure luck? Do people around you understand and help you with your assumptions? Impact mapping is a lightweight tool that helps you with quantifying and communicating your assumptions.

Continue reading

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

Att organisera flera Scrum team görs på en hel del olika sätt. Här beskriver vi likheter och skillnader mellan några av de ramverk som vi har stött på hos våra kunder och utbildare, LeSS, SAFe och Scrum@Scale.

Gemensamt för LeSS, SAFe och Scrum@Scale

I alla tre ramverken utgår man från att man i botten har vanliga Scrum-team som är tvärfunktionella och självorganiserande.

Man utgår också från att vi alltid försöker bryta ner kraven vertikalt, så att varje inkrement blir så litet som möjligt men ändå kan driftsättas separat.

Underförstått är även att man kör kontinuerlig integration och automatiserad regressionstestning, och  att man efter varje sprint har en produkt som går att driftsätta ifall man så väljer.

Continue reading

Based on the experiences with clients adopting Large-Scale Scrum, from 2007 to 2009 Bas Vodde and I wrote the first two books on LeSS:

1. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
2. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum

These are a collection of experiments related to Large-Scale Scrum, organized into three major sections: experiments in thinking tools, organizational tools, and action (practice or technique) tools.

And now, almost a decade after starting our first book on scaling agile development, comes our third book: Large-Scale Scrum: More with LeSS.

Continue reading

Hi! I recently did a podcast together with Dennis (CIO Nordnet) on #slowtofast. I walked into the podcast thinking it was going to be about Kanban and Enterprise Agile. Right! 🙂 Dennis hit me with these simple questions.. The essential elements of proper Product Management The management principles of an Agile leader How the Swedish culture is

Continuous discovery means an open backlog where everything is considered speculation and hypothesis. Continuous validation means that the user experience is validated for each release, rather than up front. This may sound like big budget to you, but let me give you a case study, about how a single team accomplished it on a tight budget.

A small team with a small budget has the advantage of not losing its head with big ideas from experts in different fields, be it architecture or user experience. The budget constraint sharpens your effort in a way that could be healthy even to a larger team.

Continue reading

Do you, a developer, have a feeling that the user stories your product owner is but a list of ideas prioritized on gut feeling only? That the relationship between them and their purpose are vague? Impact Mapping is an agile conversational tool by Gojko Adzic that may be primarily for product owners but hey, a developer needs a purpose too!

Continue reading

For  this year’s Stop Starting conference, we asked ourselves three questions: How do you develop awesome products? How do you bootstrap a successful mega project using Agile contracts? How do you use Agile and Lean thinking to turn a stagnant company around? We then picked the brains of people from real companies who have been

Vi har byggt en sajt där med goda exempel, för att inspirera företag, myndigheter och verksamheter på väg in i en upphandling att ta steget till Agila kontrakt. Check it out – agilakontrakt.se. Eller följ oss på twitter: @agilakontrakt. Turen har kommit till att berätta om Wunderkraut, som använt Agila kontrakt sedan 2010. Det intressanta är hur de i den ombytliga

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

Du har en idé om en tjänst.
Hur kan du snabbast och enklast verifiera att någon vill använda den?
Det är vad Lean Start-up handlar om.

Continue reading

If you wonder what a Scrum Product Owner need to do, here’s the checklist (in form of a mind map) for you!

Continue reading

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

– “All kod är en skuld!”
– “Den bästa koden är den kod man inte skriver!”
– “Snabbaste sättet att få upp testtäckningen är att ta bort död kod!”

Jag tror att alla är överens om att det är bra att hålla sin kodbas så liten och kompakt som möjligt. Byggtider hålls korta, testsviter går fort att genomföra, driftsättningar går fort, statisk kodanalys går fort, nya teammedlemmar kommer snabbt in i koden, risken för buggar och sårbarheter hålls nere och så vidare. Kort sagt, man blir mer lättrörlig!

Så alla utvecklingsteam borde ägna tid åt att inte bara skriva ny kod, utan också att faktiskt städa efter sig. Men det är lättare sagt än gjort…
Continue reading

Just back from Mix IT in Lyon. A bit rare to visit a French conference so was cool to meet people from the French community and see what they are up to. Some reflections: Saw a cool presentation on Prioritizing portfolios using Cost of Delay by Özlem Yüce. No doubt mr Don had an idea

I denna video berättar jag om vikten av att se till end-to-end ledtid och att den största förbättringspotentialen hos en organisation med Agila team ofta ligger i  stegen innan utveckling påbörjas. (for english readers: In this video I tell about the importance of improving end-to-end lead time –  not only think about the development portion

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

In software, one of our favorite tool to deal with uncertainty is iterations. But is it always the better option?

The last week I’ve got the question two times of how to address critical in deliveries from subcontractors. For example: hardware, preparation of land, machinery, buildings or third party platform updates.  How can these be addressed? Do iterations hold the answer? Are there better options?

Let me introduce lean flow thinking and show how it can be used to improve the outcome of critical third party in deliveries in your projects.

Continue reading

This is basically a 1 day product ownership course compressed into a 15 minute animated presentation.

Over a million views! Some call it “The best 15 minutes on the Internet” 🙂

There’s obviously more to product ownership than this, so see this is a high level summary.

• Here’s the complete drawing (.png format)
• Here’s a downloadable version of the video, in case you don’t want to stream (.mov format, 90 Mb)

Special thanks to Alistair Cockburn, Tom & Mary Poppendieck, Jeff Patton, Ron Jeffries, Jeff Sutherland, and Michael Dubakov for providing many of the models, metaphors, and ideas that I use in this presentation.

Translations: (see also the translation guide by Cédric Chevalerias)

• Chinese – simplified (subtitles)
• Chinese – traditional (subtitles)
• French(subtitles)
• French (voice)
• German (subtitles)
• German(voice)
• Italian (voice)
• Japanese (subtitles)
• Polish (voice)
• Portuguese – Portugal (voice)
• Portuguese – Brazil (voice)
• Russian (voice)
• Spanish (subtitles)

Below is a full transcript in english. But I recommend watching the video instead of reading the transcript. The video is 100% visual, the transcript is 0% visual…

Continue reading