Tag Archives: development

Below is the answer I posted in response to the question “How do UX practices fit with agile development practices?” on Quora.

My team has had great success leveraging UCD and Agile in combination. (Disclaimer – we are using the spirit of both processes, not the formal execution of both). Here’s how we commonly work.

  1. When planning iterations, we focus on defining high-level user stories and work with the business to prioritize those stories. Note – we include refinement user stories as well as new features.
  2. Once we have business priorities, the team (UCD & Dev) discuss the high-level user stories to gain agreement on what seems achievable in the next iteration. This may or may not include a round of planning poker but it does really get at estimating & sizing based on complexity, resources, and time. The key here is that both UCD & Dev understand which elements they have dependencies on one another for.
  3. We then present a recommended scope for the iteration and gain agreement with the business.
  4. Once agreement on the high-level user stories is gained, we work to detail those user stories with more granular requirements (ability to… ).
  5. As we enter the iteration, UCD goes deep on UI and design elements impacting the user experience by iterating on mockups and seeking user feedback on designs. Meanwhile, dev starts on the technical or architectural tasks.
  6. As UCD firms up the UX designs, the dev team can leverage the mockups as guidance for the front-end and point out any unexpected technical issues as necessary.

We’ve found this process allows a great amount of flexibility to evolve the designs as we learn more through validation with users.

http://www.planningpoker.com/detail.html
http://en.wikipedia.org/wiki/Planning_poker

What is the goal of planning poker?

  • The goal in planning poker is to arrive at a shared & understood estimate for desired capabilities in a short and inexpensive manner.??
  • It provides a comparative view of the technical complexity of delivering desired capabilities.
  • It is not to derive an estimate that will withstand all future scrutiny.
  • Sprint & Iteration planning then uses these estimates coupled with the business priorities in order to select scope.


How does planning poker work?

  • An overview of a given user story (or capability / feature) is provided. The team is given an opportunity to ask questions and discuss to clarify assumptions and risks.
  • Each individual lays a card face down representing their estimate.
  • Estimates should cover the full technical scope including design, discovery, development, and unit testing.
  • Units used vary – they can be days duration, ideal days or story points.
  • Everyone calls their cards simultaneously by turning them over.
  • People with high estimates and low estimates are given a 'soap box' to offer their justification for their estimate and then discussion continues.
  • After the soap box discussion, we repeat the estimation process (another round of poker) until a consensus is reached.
  • In many cases, the estimates will already converge by the second round. But if they have not, continue to repeat the process. The goal is for the estimators to converge on a single estimate that can be used for the story.?? Again, the point is not absolute precision but reasonableness.

Why Planning Poker?

  • Planning poker brings together multiple expert opinions to do the estimating.
  • A lively dialogue ensues during planning poker, and estimators are called upon by their peers to justify their estimates.
  • Studies have shown that averaging individual estimates leads to better results as do group discussions of estimates.

http://bit.ly/14Mufh

Like the concept and the quotes, don’t care for the examples

http://tinyurl.com/cnv78z

For weeks after reading this post I kept being reminded of it.  It covers how difficult the balance is between planning for long-term goals at the expense of short-term success…. example – we plan to go worldwide so we should have a multi-language solution. 

In my opinion, we see this all the time in enterprise efforts.  Some call it overengineering but I prefer to think of it as having lost perspective to what is really valuable.  We seem to get carried away with more and more rich features that are only used by a very small subset of users (assuming they have the patience to find out which of the 100 features they will use).

http://bit.ly/2JwUaP

Really fascinated by this post as it seems to suggest the thing that drives us to embrace change is “annoyance debt” whereby the user base just gets sick and tired of being annoyed with not being able to do little but frequently performed activities.  We don’t want another feature, we just want the features you have to work 100%.  The premise is if each release you tend to some of this “annoyance debt” then your users will still put up with some annoying things because at least you are iteratively improving… sucking less each release.

I think this is a bigger problem than many realize.  Although there are cases where I didn’t know I wanted a feature until it became available, more often than not I only discover those unscratched itches when my annoyance with a certain application has grown to such a degree that I am open to exploring alternatives.