Acceptance criteria vs. Acceptance tests Recently, i had an interesting discussion with my good friend Xu Yi. We discovered an interesting difference in our way of thinking about acceptance criteria and acceptance tests. In his thinking, acceptance criteria and acceptance tests have one-to-many relationship; while in my thinking, acceptance criteria
As to this topic, I am only talking about project managers in software industry. Same thoughts may not apply in other industries. Traditional project managers There is traditionally contract game between business (or product or customer) and R&D (or IT or technology or vendor). In the beginning of
Scrum framework is based on empirical process control, i.e. you inspect and adapt to achieve the goal. In my CSM course, we do an exercise to relate empirical process control with events defined in Scrum framework. The below table is one typical outcome. Event Goal Who Information for Inspection
PO (Product Owner) is defined as single person in Scrum. However, for various reasons, in practice a team may be formed to fulfill the role of PO. I am using the term of team rather freely, strictly speaking, some of them are only working groups. I'd like to
In my recent CSPO (Certified Scrum Product Owner) course, we had a discussion exercise about how PO breaks and/or gains trust from team. I'd like to share some points so that any PO can keep those in mind while working with the team. How does PO break
The purpose of Daily Scrum is for team to inspect and adapt towards Sprint goal. The mechanics seem so simple, while in practice its purpose is often not well achieved. Here's some experiments that may help you find better mechanics to achieve purpose. * Separate "inspection" and
During Agile adoption and transformation, there's an important question of "what change do you introduce next". Approaches I see a few approaches to introduce the next change. * Adopt Scrum, which means to introduce Scrum roles - cross-functional team, PO and SM; Scrum events - planning, daily
Recently, i attended a training on Kanban. To drive continuous improvement, Kanban has its main or even sole focus on shortening the lead time. I was impressed by results from a couple of case studies shared in the training. This triggered me to think further on how improvement is achieved
Recently, I attended a workshop by David Hussman, and story mapping was one of the topics. Since I had rarely used story mapping, while didn't realize its Indispensability, it made me think of why. * Why story mapping? The introduction of story mapping technique is a response to lack
Much has been said and written about how you can measure being "Agile" in software development. I, for one, had my own share writing an article about it in an online Agile magazine back in 2011. Of which, in retrospect, makes me laugh at how bad it is.
During the last months, I've been working on this article. It shares stories about the software industry in Singapore and my perspective on why it will have to improve a lot in the future. I've written this article because I've frequently have discussions on
"There's always a duck" is a LeanPub book written by Elisabeth Hendrickson (a friend of mine). You can find the book here. Since it is a LeanPub book, I can't review it on Amazon.com therefore I'll just post it on my
Today, accidentally, we invented a new term: Dependency Objection :) We started using dependency objection in design by preventing dependencies so that we don't need to inject them anymore later. Thus prefer to do DO over DI. Interesting...
PSPI (Potentially Shippable Product Increment) is an important concept in Scrum framework. At the end of sprint, team is supposed to deliver a potentially shippable product increment. The focus of PSPI is on the readiness of the delivery. MVP (Minimum Viable Product) is a term popularized in lean startup. It&
Self-organizing team is an essential element in Scrum. ScrumMaster has the responsibility to help team become self-organizing. Agile coaches often give the suggestion that you should take the problem to team. While this is a good suggestion, it is too much simplified thus not used effectively in practice. I'
I worked with an organization that adopted Scrum for months. Their traditional release milestone for "content frozen" still kept, and I found that they had assigned all features to teams in sprints on that milestone. I asked, "wouldn't it be change on requirements while you