Posts Tagged ‘ux’

This is a post in a series on the talks that I attended at my first ever Agile Africa Conference in Johannesburg. All posts are based on the sketch-notes that I took in the sessions. agileafrica

Despite its short length, this was an interesting talk for me. There were two new ideas that I’d not been exposed to before and quite liked. The first was the term “Most Loved Product” (MLPLOL-48). A MLPLOL-48 (rather than MVP) is a slice of a Product that can be used to gather feedback about the user experience i.e. does my Product makes my customer smile? The important part about a MLPLOL-48 is to not forget the smiley!

CaptureSecond, and largely related, was the concept of what a MLPLOL-48 vertical slice needed to consist of. Whereas vertical slices traditionally relate to the stack on which the Product was built, the UX slice needs to include the functional, reliable, usable and emotional design layers to be a full vertical slice.

The presenters also touched on user feedback and how it was important to consider all aspects of the user experience: what they hear, see, say, do, feel and think. They did caution, though, that “not every colourless liquid in a glass is water”, so although user feedback can tell us what they are hearing, seeing, saying, doing, feeling and thinking; we need to probe a little deeper to determine WHY they are having that experience.

Have you ever heard of a MLPLOL-48? What are your thoughts on the UX vertical slice concept?

Dual Track Scrum

Dual Track Scrum

This week I stumbled across an article which referenced something called “Dual Track Scrum” (see the links below). Intrigued, I researched a little more and was fascinated to discover that there was a documented process/approach to product development and delivery that was very similar to what had evolved for a product team I previously worked with.

This isn’t the first time this has happened to me. The last significant deja vu experience was when I found that there was a name for a software development approach that included: time boxing; daily team check-ins; planning and estimation as a team; work defined on a physical card on a white board; a definition of done for the time box that included all delivery activities; and a list of features that could be traded in and out if not yet started. Yes, that was the day I discovered that the approach our team had “created” to successfully deliver an off-shore project was, actually, called Scrum.