I have started using Pivotal tracker for a project I'm working on. Conceptually, this seems really cool and I'm interested in using the agile model. However, I have one problem with everything talked about in the video.

At 4:19 in the linked video they talk about story acceptance and how it should be done by the project owner. This concept sounds great on paper but I'm not sure I can actually get the project owner to sit down and try out even half of the new features I create, let alone all of them.

My question is: how do you approach a product owner about the work that this flavor of the Agile Model asks of them? What do you do if they refuse to participate in acceptance testing?

  • 1
    "If i don't get feedback about what's wrong, then it's right -- and i'll be charging you by the hour for subsequent changes". :)
    – cHao
    Feb 4 '14 at 23:49
  • @SparK This is an interested problem I've seen pop-up in the Agile documentation and discussions. There seems to be very divergent definitions for most of the language used in the Agile bubble. This is true of most things, but to my limited experience it seems like this is a larger problem in the agile world. Feb 6 '14 at 20:23
  • 1
    Sometimes my wife likes me to help her cook by tasting and offering honest suggestions on improvement along the way. Sometimes though you just want a burger so you go to a fast food restaurant and give your order up front and have a reasonable expectation of what quality (or lack thereof) to expect. Restaurants have been having troublesome customers though from their very existence who are never satisfied and ultimately cost the restaurant money in do-overs and pandering. It is not a problem that can be solved as long as some clients don't want to invest the time to ensure highest quality.
    – maple_shaft
    Feb 7 '14 at 12:30
  • The good news is this product owner probably doesn't have time to add new features during the sprint.
    – JeffO
    Feb 13 '14 at 17:11

What you are mentioning is a classic problem that many companies have introducing agile development.

Unfortunately, there's no easy solution.

  1. For the specific problem of acceptance, the "standard" workaround is having someone in the team acting as a proxy for the product owner. This is not great but it can work as long as this person takes care to demo regularly to the owner so they maintain the same perception of what is accurate.

  2. Product owners are supposed to work together with the team on a day-to-day basis. This is because typically units of work (i.e. stories) are negotiated during development. E.g. a UI for a story is not designed beforehand. Its design is negotiated during development, so design decisions are validated on a working solution instead of a piece of paper. There's no easy solution here. If everything is decided beforehand, there will be quality issues or inefficiencies, because it's really hard to design everything beforehand.

  3. There's often lack of clarity on what the acceptance tests of a user story are. An absentee product owner often will not provide enough, or any, acceptance tests to make it clear what the final "black and white" objectives of a story are. Unfortunately, this means that someone in the team, possibly a QA person, will gradually replace the PO on this matter and this is not a good solution, since many of these tests are quite arbitrary in nature and teams often end up disagreeing on when a story is complete.

  4. Probably the biggest problem, though, is the lack of agility. Having a set of stories and a "perfect" idea of a product is not a good implementation of agile. If everything you need to do is known in advance, you probably don't need this methodology. The strength of agile is that it maximizes the value delivered by changing the project scope and direction in flight to take advantage of the increased product knowledge that it's acquired during development. If there is no one to guide this process, there is basically no point developing with a methodology only "theoretically" agile.

  • 2
    Further to point 1: some teams (including many I've been part of) make use of a Feature Owner as a proxy product owner. The Product Owner gives up ownership of a feature for a period, and accepts that his vision and the delivered feature may differ (at least for a while). The only difference between this and @Sklivvz's proxy is that the product owner is accepting the risk in advance, rather than the team accepting the risk during development.
    – Paul Hicks
    Feb 5 '14 at 1:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.