Saturated Testing

Nice post from Rikard Edgren. If additional testing in an area doesn’t give any important, new information, and is it worth the effort? I have found situations in which additional testing would not change the outcome, but not very often.

Perhaps a more interesting question from agile perspective is "will adding additional tests here increase or decrease the total utility of my automated testing suite?"

If adding a set of tests to your automated unit tests make it too long (long enough that developers won't run them as often?), then maybe it would decrease the total utility of your test suite

Good pain

I was reading Rajesh Setty's blog this morning and noticed a Tweet he had posted that said "The pain of discipline is now, the pain of regret is later." There was a related tweet from someone else that said the pain of regret is always greater than the pain of discipline.

One of the things that I noticed in my first year or so as a Scrum product owner was that simultaneously the best and worst part of the process, at least for me, was the moment in the planning session when I drag items from the backlog into the new sprint.

Inevitably, I always wanted to try and squeeze one or two more items into the sprint than would fit. I had to acknowledge that we couldn't do all the work that I had hoped we would be able to (worst part). And having acknowledged that reality, then I would work with the team and stakeholders to make hard decisions about what we were NOT going to work on. We would end up with an amount of work that we were comfortable we could finish (best part).

In this moment, I was experiencing the pain of discipline.

Infinite possibilities-unlimited freedom, or unsolvable problem?

I read an interesting post by Jon Miller on Gemba Panta Rei today. It asked the question "Is an infinite number of possible solutions is a good thing or a bad thing?" Ultimately he concluded that it is a bad thing. A problem with an infinite number of solutions is indistinguishable from an undefined problem. The act of defining the problem creates constraints on the range of solutions.

I've seen this in action many times. I'm a product owner for a team that uses Scrum. I present the team with a user story. They respond "Pete, this is way too vague, we can't estimate how much work it is." So we talk about different ways of breaking the problem up into smaller chunks. Eventually we have several smaller, more constrainted user stories that we can estimate.

The possibilites are no longer infinite, but now we see ways to solve the problem.