A simple recipe for using collaborative sketching with Agile and Lean UX teams
Design Studio is a quick collaborative approach to considering lots of possible solution ideas for a new product, a feature, or enhancement.
In a design studio, everyone sketches and shares ideas. By everyone I really mean everyone: UI designers, developers, testers, product managers, business stakeholders, end users, customer service people, and anyone else interested. Everyone feels involved and engaged. Everyone quickly learns that the best ideas aren’t any one person’s but a mashup of everyone’s. And, on top of all this, it’s fun. And, you deserve a little fun.
Jeff Patton & Associates has designed a fast-paced, high energy event for Product Teams
If a typical course is like learning to swim from a powerpoint deck, our 5-day immersion is like being thrown into the deep end of the pool. But, don’t worry. We’re here with water wings and some good coaching to keep you from drowning.
I wrote a book. This is my friend Liya holding her copy. I’m not nearly as pretty.
It’s About User Story Mapping
I’m known for coining the term “story mapping,” and the book is about that. I may have been lucky enough to coin a sticky term, but the term describes a way of work with product design that I’ve seen lots of smart people doing for years.
From the Editors of StickyMinds.com – Managing an agile project based on uncensored “Very High,” “High,” and “Low Priority” user stories or backlog items used to induce stress on Jeff Patton. So he learned to implement a combination of prioritization techniques to get these lists–and the job–under control. In this week’s column, find out how Jeff utilizes MoSCoW and business goals to make sense of prioritization.
One of the more challenging things about moving to agile software development is breaking up your software requirements into small, buildable chunks. Often these chunks are expressed as simple, single-line “user stories” or backlog items that we intend to develop starting with highest value or highest priority. If you’ve spent any time in software development, I suspect you’ve seen the prioritized list where most items in the list range from high priority to “very, very” high priority. These lists used to stress me a lot. Although they’re still a bit annoying, today I better understand the reasons they are that way and have some easy techniques for working with them that leave me significantly less stressed. (more…)
How Kanban-style development gives us another way to deliver on Agile values
Years ago — Feb 25th 2008 to be exact — I wrote this draft article. At the time Kanban development was a cool new thing — bleeding edge Agile. Due to a series of unfortunate events the article wasn’t published in the magazine it was originally target for. I’ve been sitting on it for quite some time, so it’s time to open-source it.
What the product owner needs to worry about isn’t in the product backlog
If you’ve read one of my blog essays before, you know this isn’t going to be a quick thought, but a bit of a long discussion (read “discussion” as “rant”).
This particular discussion describes what I see as a problem in agile development – sort of a practice vacuum. One of the most difficult roles in an agile process is the product owner or agile customer. In this essay I describe the problem as I see it, and sketch what I see as a mental model and some practices that product owners can use to begin to fill that skills vacuum.
Warning, it’s a bit of a long rant. Go grab a cup of coffee and get settled in.