A Crash Course for Non-Technical Stakeholders who need to Manage Product and App Development

Project Rhythm

How do you set priority, check progress, and stay focused on the right thing on the monthly and quarterly level? The Concepts of Pivotal Tracker video outlines that process in the context of Pivotal Labs’ style of Extreme Programming flavor of agile. A Responsible Recipe for the Fewest Possible Meetings goes on to specify a starting point for healthy team communications structure—enough so everyone knows what’s going on (or knows enough to probe more deeply), but not so much that unnecessary time is burned in expensive meetings.

Building Product

To ensure you’re building the right thing (and continuing to ask “what’s the right thing?”), start at a high level by learning how to Use Lean Hypotheses to Define a Minimum Viable Product. The exercise which we usually use to outline this is detailed in Inception: Knowing what to build and where you should start. On a more granular level, perhaps the most high-leverage skill is learning How to write Well-Formed User Stories. As a project continues and you need to continually capture ideas it can be helpful to Set your sights on the next Milestone with an Idea Board. For those times when you need to do long-term planning (despite the fact that your backlog ought to be short-term and granular), check out
Long-term Estimation in an Agile Environment, or: How I Learned to Stop Worrying and Love the Assumptions Label.

Links

<br />[A Responsible Recipe for the Fewest Possible Meetings]: http://blog.pivotal.io/pivotal-labs/labs/fewest-possible-meetings
[Concepts of Pivotal Tracker]: http://bit.ly/conceptsofpivotaltracker
[How to write Well-Formed User Stories]: http://blog.pivotal.io/labs/labs/well-formed-stories
[Inception: Knowing what to build and where you should start]: http://blog.pivotal.io/labs/labs/agile-inception_knowing-what-to-build-and-where-to-start
[Long-term Estimation in an Agile Environment, or: How I Learned to Stop Worrying and Love the Assumptions Label]:http://blog.pivotal.io/pivotal-labs/labs/assumptions-label
[Set your sights on the next Milestone with an Idea Board]: http://blog.pivotal.io/pivotal-labs/labs/idea-board
[Use Lean Hypotheses to Define a Minimum Viable Product]: http://blog.pivotal.io/pivotal-labs/labs/lean-hypotheses

Types of Design

I just blogged about Types of Design over at the Pivotal Labs blog.

“Design” is a messy word, and describing which type of design you mean can be tricky. Sometimes it’s more helpful to describe types of design not as crisp definitions—”Visual Design looks pretty, and UX has boxes and arrows”—but instead in the spirit of Family Resemblance, i.e.:

things which may be thought to be connected by one things which may be thought to be connected by one essential common feature may in fact be connected by a series of overlapping similarities, where no one feature is common to all.

Check it out, and let me know what you think in the comments!

The Benefits of Pair Design

I just blogged about The Benefits of Pair Design over at the Pivotal Labs blog:

design-pair-4

How is design different for Agile product development?

“Design” can mean many things, but designing products for Agile software development methodologies present distinctive challenges. Engineers build software more quickly (and change it more rapidly) than most…

Check it out, and let me know what you think in the comments!

InVision takes a look Inside the Design Team at Pivotal Labs

invision-inside-labs-design

The fine folks at InVision did a nice interview and write-up of our design practice. Check it out!

Balanced Team Sunday Salon at Pivotal Labs

I just blogged about the Balanced Team Sunday Salon at Pivotal Labs over at the Pivotal Labs blog.

This Sunday Pivotal Labs hosted a Balanced Team Sunday Salon following the three-day LeanUX NYC conference. LeanUX was chock-full of amazing talks and workshops, and the ensuing sentiment was my brain hurts! The Balanced Team Sunday Salon was a chance to recover, process, and reflect. We started off with brunch: bagels and bellinis…

Check it out, and let me know what you think in the comments!

How To Maintain Separate Design and Development Backlogs

I just blogged about How To Maintain Separate Design and Development Backlogs over at the Pivotal Labs blog.

Previously, we discussed when to use different types of backlogs, categorized various types of stories, and described a general flow for agile design. In this post we won’t rehash that material, but instead will describe some of the practices specific to separate Design and Development backlogs.

Check it out, and let me know what you think in the comments!

How To Integrate Design in an Agile Backlog

I just blogged about the How To Integrate Design in an Agile Backlog over at the Pivotal Labs blog.

WHEN SHOULD I USE AN INTEGRATED BACKLOG?

An integrated design backlog is appropriate for small- to medium-sized projects (i.e. teams which can be fed with two or fewer pizzas), focused on a single platform. It can accommodate teams which have designers that code, as well as designers who don’t.

Check it out, and let me know what you think in the comments!