Category Archives: Scrum


Tell a story at the daily standup

Yesterday during my keynote at the Agile Testing Days 2012 I said I see a lot of standups, where testers report on their yesterday’s work in the following way:

Yesterday I tested the thing with the stuff. I found some bugs, and filed them. Today I will test the foo with the bar.

I think this is horrible test reporting. While concluding the fifth beta of Elisabeth Hendrickson‘s upcoming book Explore it! I found a few more hints in the same direction. On the same line I will relate good test reporting during the standup to what for example Michael Bolton talks about when it comes to test reporting – we should tell three stories during test reporting:

  • a story about the product
  • a story about testing
  • a story about the process
Continue reading Tell a story at the daily standup

Certified Scrum Manager – somewhat more than a rant

In the past I have been more than skeptic about certifications. I even wrote about my minimum requirements for a certification programme that might (or might not) add value in an article called Meaningful Certification?. Despite the split between the two larger organizations (and their early leaders) on Scrum – the Scrum Alliance and – yesterday I noticed that the certification scam has taken on new levels with a program called Certified Scrum Manager (IAPM). Here is my honest critique about it, and I will try to rant as few as possible about it.

Continue reading Certified Scrum Manager – somewhat more than a rant

Tracking testing on the Scrum taskboard

Today, a colleague of mine, Norbert Hölsken, started off a discussion in our internal communication channel. He asked:

How do you treat bugs on the taskboard that are found during testing? Create a new test for each bug, and put the test task back in ToDo? Or create a bug, and a bug-follow-up testing task?

As it turns out there are a lot of valid reasons to do it one way or another. Yet, the answer “it depends” does not help – neither a Scrum Coach, nor a tester working in a Scrum environment. So, I started raising some of my experiences and concerns, and some of my other colleagues replied as well.

Skip forward three hours, and I am writing a blog entry on my thoughts about it.

Continue reading Tracking testing on the Scrum taskboard

Some surveys on the state of our craft

One of my colleagues made a claim yesterday which I would like to put some numbers on. I raised the question on twitter, and received suspicious answers about the numbers of my colleague. Please forward this survey to anyone you know who is programming: It consist of just four question, so you should be able to answer them in a few minutes.

Over twitter I also received the feedback that things are worse for testers. I would like to put numbers on that as well. Therefore I also put up an equally small survey for tester: Please forward this survey to anyone in the software business that you know of.

From time to time to I will publish some of the results. I aim for end of January for the first set of data.

Lessons from complexity thinking

While Diana Larsen was in Germany in July she spoke about a course she was currently taking called Human Systems Dynamics. Since then some of my colleagues started to dive into it. So did I. I didn’t take the course, but decided to go for some of the books on it. The first one I came across is called Facilitating Organization Change – Lessons from complexity science, and deals with a lot of stuff on complexity science, self-organization, and how to introduce changes in a complex adaptive system (CAS). These are some of my first thoughts after finishing the book.

Continue reading Lessons from complexity thinking

The case for slack

Some while ago, J.B. Rainsberger posted a case for slack, and that you might be sabotaging your peoples training. I think it was Kent Beck who pointed me to the self-similarity of nature in eXtreme programming explained. In this post I’m going to take a closer look on how we learn, and how nature is self-similar in this regard, and what we may derive from this.

Continue reading The case for slack

Scrum Norris

Yesterday evening there was a thread of scrumnorris going over twitter. Since these messages were in German, let me translate them.

  • Chuck Norris is ScrumMaster and ProductOwner – simultaneously.
  • Chuck Norris can do 6-month sprints.
  • Chuck Norris wears Timeboxershorts.
  • Chuck Norris does not move story cards, he moves the taskboard.
  • Chuck Norris does not estimate, he knows.
  • Chuck Norris pairs alone.
  • Chuck Norris starts project with a Roundhouse-Kickoff.
  • Chuck Norris is allowed to appear late at the stand-up.
  • Chuck Norris sits on the stand-up meeting.
  • Chuck Norris has implemented everything at the planning meeting.
  • Chuck Norris does not estimate user stories, user stories estimate him. (This doesn’t translate well.)
  • Chuck Norris writes the code first, then the test.
  • Chuck Norris is not afraid of bugs, bugs are afraid of him.
  • Chuck Norris does not do Kanban. He does not know limits.
  • Chuck Norris does not pull, he pushes.
  • When Chuck Norris says “done”, then it’s “done”.
  • Chuck Norris does not deploy, he develops on the production environment.
  • Just Chuck Norris knows, that a real burn-down requires napalm.
  • Chuck Norris has no burn-down chart. Around him everything is already burnt down.
  • Chuck Norris answers just two questions on the stand-up meeting. Chuck Norris does not know obstacles.
  • Chuck Norris does not prioritize the backlog.
  • Chuck Norris takes two baby-steps at once.
  • Chuck Norris does not use test-driven development. Chuck Norris always drives.
  • Chuck Norris is the prioritized backlog.

Any additions?