coaching and training for adopting agile and scrum
Posted in Agile, Agile Success

Writing perfect user stories

To write perfect user stories, the do this:

Step 1: Ask users what they need from the software and why.

Step 2: Look at the most common answers and try to express them in the form “<someone> can <do something they need>, in order to <main benefit>”. At this point, only write a small number of stories, like 20–50, so that each story is “an epic”, big and unclear, but captures an essential need for some user or group of users. In some way, validate with users that you’ve understood them.

Posted in Agile Success, General

Times are not a-changing…

First of all, welcome to my new website!

Or more precisely, the same website, but with a new appearance. So it just looks new. But anyways, welcome!

Thanks all the people who actually made it happen - you know who you are.

Posted in Agile Success

Coaching a Team to Get Started

In those times when I have had more time to work with a team to get them started, I have used the following general outline and found it working. By working I mean, it has struck a good balance between effort invested and value delivered. Investing more time could make things even faster, but not proportionally. Investing less time would reduce value and impact disproportionately. You know.

The Plan for Team’s First Sprints

* Pre-game *

1) Kick-off meeting on first day, to get started (this is more
facilitation than training), including

  • What are the things we don’t know? How critical are they to know before we start Sprint 1?
  • How do we learn together?

2) High level conversations – concept, requirements, UX, design, architecture, technologies, …

Posted in Agile Success, Scrum

The Importance of Two Things in Agile

To me, there are two things in Agile from which everything else follows. Before moving on, what are those two things in your opinion?

Getting things DONE

The first thing is the potentially shippable product increment, delivered frequently. In Scrum this means that at least at the end of every Sprint, the technical quality of the product meets the criteria of shipping the product (but it doesn’t have to be shipped, for whatever reason, such as not having a shippable feature state). In Kanban flow, this state is reached at the end of every developed item.

This state means, for example:

Posted in Agile, Agile Success, Scrum

UI Design in Scrum

Again, I’ll post an email response to question from an alumni. This post is also available on Futurice Blog.

The question:

I am working on an agile project and I don’t know when to incorporate prototyping.

Posted in Agile Success, Organisations

Hull Speed for Systems

TL;DR: Work smarter, not harder.

I have noticed that all systems have some natural capability for productivity, value delivery and quality. As the people in the system gain experience in the system, their performance will start reaching that systemic speed. Just like with a ship, this happens quite easily, but when the “hull speed”* is reached, the amount of effort / power to go faster dramatically increases, up to the point that a certain speed seems unsurmountable regardless of power expended. In systems, we can perceive this e.g. in overtime, which does not yield real benefit since the extra effort translates to more mistakes and other negative factors that detract from real progress.

I continually observe that also in the ball point game, where people psyche themselves to try harder, but they still get the same result.

Posted in Agile Success, Project Management

Story of Release Planning

While I have many stories of release planning, I like to share this one.

Getting started… a little late

I was coaching this game team/organization. The original plan for the next game called for about 6 months of design and development. However, due to other pressures, a lot of things were prioritized over this project and when the first people were able to start the work, only three months were remaining. There was hope that using Agile could help them speed up the development (through prioritization, backlog refinement and faster development), but it was still known that it will be tough.

At the beginning of the work, the game concept was available. A backlog had been built collaboratively with the team. For the first two sprints, only half of the team was available, and they started on the most critical stories. During this time, the backlog was radically refined and prioritized (i.e. features slashed), up to the point that PO started to be concerned that “there was no fun left”.

Posted in Agile, Agile Success, Organisations

“How Does Agile Make Me a Better Developer?”

In this blog post, I’ll share a bit of a conversation I was having with a participant of my CSM course, who had his team ask provoking questions. I’ll share the questions and my responses. Remember that this is a conversation piece, so I can’t guarantee it’s more than opinions :).

Snippety snip, start the email here (the original email in quotes, my response in blue):

I had a great retrospective with the team that was having buy-in issues last week and they expressed some fundamental questions that they had not been given answers to.

1 2