Archive for the ‘Product Owner’ Category

• Best Links of the Week – Jan 19 2010

  Date: 2010.01.19 | Category: Agile, Pair Programming, Planning, PMI, Product Owner, Scrum, Transitions | Response: 0

  Continuing with links to the best of the blogs since last week.

  1. Three things I wish I knew before jumping – PMP and Certified ScrumMaster, Pat Guariglia, shares some lessons learned after his first Scrum pilot project in 2007.
  2. Mike Cottmeyer on the Agile PMP – InfoQ has a 78-minute video from Mike Cottmeyer’s Agile 2009 talk on how Agile’s approach to managing cost and time reduces project risk rather than the traditional approach of managing scope.
  3. Determining how Agile you are comparatively – discussion on the Comparative Agility assessment for teams looking to understand how Agile they are doing in seven areas: teamwork, requirements, planning, technical practices, quality, culture and knowledge creation.
  4. Demystifying the Product Owner role – Roman Pichler provides some truth about the Product Owner role and clears away some myths.
  5. Self-discipline & self-organization – Cutter Consortium Fellow, Jim Highsmith, emphasizes the need for discipline and excellence on Agile teams.
  6. Eight reasons why the estimates are low – some common reasons why software estimates are often too small.
  7. How pair programming really works – the IEEE publishes an article sharing four mechanisms that can improve pair programming.

• Best Links of the Week – Christmas 2009

  Date: 2009.12.25 | Category: Agile, Coaching, Links of the Week, Product Owner, Scrum, ScrumMaster, Team | Response: 0

  A bag full of Christmas links.

  1. Grooming the Product Backlog – Laura Brandenburg talks about the role of requirements management through the Scrum Product Backlog.
  2. Make the Product Backlog DEEP – more on good practices for maintaining the Product Backlog from Mike Cohn.
  3. Why is Agile so Hard to Sell? – describes some of the issues growing Agile in the enterprise.
  4. Is Scrum for Lazy Project Teams? – looks at the misconception that Scrum does not challenge teams to work their hardest.
  5. When the Scrummaster Becomes the Impediment – different perspectives on how to solve the problem when the Scrummaster becomes a bottleneck.
  6. A Day in the Life of a Scrum Team – a short 6-minute YouTube video of a Scrum Team in their native environment.
  7. Agile Business Analysts – what is the role of the business analyst on an Agile team?
  8. Building trust – five concrete things you can do to build trust on your teams.
  9. Something in Agile Needs Fixing – Rob Bowley summarizes the Open Space discussion on the topic of “Agile isn’t solving our customers problems because they aren’t here.”

• Best Links of the Week – Dec 18th 2009

  Date: 2009.12.18 | Category: Agile, Coaching, Communication, Links of the Week, Product Owner, Scrum, ScrumMaster, Team | Response: 0

  Here are links to the best of the blogs for the week of Dec 18th 2009.

  1. A ScrumMaster’s Checklist – a comprehensive checklist from Michael James offering four areas a ScrumMaster should pay attention when coaching: the Team, the Product Owner, the organization and the technical practices.
  2. Agile Leadership: Methodology Ain’t Enough – the Hacker Chick brings us a blog article about the management beliefs and behaviors which support the growth of Agile teams.
  3. When Should QA be Engaged in an Iteration? – Hiren Doshi PMP discusses the role of QA on a Scrum team and tackles the myth that QA folks “have nothing to do until the end of a Sprint”.
  4. Five Reasons to Hire a Coach for Agile Teams – Ester Derby talks about five pitfalls of DIY (Do-It-Yourself) Agile coaching.
  5. Scrum Doesn’t Do Anything – explanation of how Scrum only comes to life when people are added to the framework and the importance of the following the rules by Tobias Mayer.
  6. Practical Agility: On Estimation – Dave Rooney describes the Agile estimation lessons he learned while undergoing a recent move.
  7. Overcoming Technical Challenges for Adopting Agile Methods in the Enterprise – Vijay Narayanan over at InfoQ discusses the importance of having an development environment which supports your Agile process.
  8. Flipping Out – short description of how Flickr uses Continuous Integration and a Single Code Base to add features to their application without branching.

  There was a lot of great stuff to read this week, unfortunately I can only go with eight or so entries.  Cya next week!!

• Focus on Adding Value, Not Features

  Date: 2009.06.18 | Category: Agile, Planning, Product Owner, Scrum | Response: 0

  I had an interesting conversation today with one of the software testers in China who was having difficulty understanding some planning concepts in Scrum.  She wanted to know if a Scrum team finished all their work early in a Sprint, would it be OK for the Team to take some planned work for the next Sprint into the current.  My first response was, “No, that work is already planned for, so the Team takes in a new piece of work that can be completed by the end of the Sprint.”  She was having a hard time wrapping her head around the concept until we got to the whiteboard and sketched out what I was thinking.  Since it was such a great conversation, I wanted to capture the explanation for others.

  Suppose you have a Scrum team and they have constructed the following release plan of their user stories.  Each user story has a value (indicated by the $ sign) and a relative size to the others.  The total value provided by this Team over the 3 Sprint release is $20.

  This is committed work that the Product Owner can take to the stakeholders with reasonable certainty it will be completed when the release date arrives in 6 weeks.  When I say reasonable certainty, I mean something along the lines of 85% confidence level.  We are very confident all the stuff in the 1st Sprint will be done, less so about some of the low value things in the 3rd Sprint.

  Keep in mind when you create an Agile release plan, you are working with incomplete information.  We spend just enough time with the user stories to understand the high level scope, high level implementation details and we provide a high level estimate.  Since we do not spend a lot of time with the details, our initial estimates for the release plan may be too high or too low.  We accept this inaccuracy because it allows us opportunities to provide greater value to the stakeholders and customers.

  In practice, this does not present too many problems because there are three forces at work on Scrum teams to ensure the stakeholders get the value they expect (and often times more).

  1. On Agile teams, the stakeholders are entitled to the most value from each programming week.  If the Team has extra capacity, they take on extra work.
  2. At the beginning of each Sprint, we ask the Team to re-estimate the user stories based on their knowledge of the app, individual skill sets, ability to work as a team and recent experience working with the app.  Normally, an implementation detail passed over at release planning with surface during Sprint Planning and that will either make the story real easy or expand the scope.  Either way, we have the Product Owner on hand to make adjustments.
  3. We focus on delivering complete chunks of value, as opposed to coding the most features possible.  In Scrum one does not allow unfinished work to cross from one Sprint to the next nor do we allow Scrum teams to start work that cannot be completed by the end of the Sprint.  No unfinished work may cross the Sprint boundary.

  Back to the original question – if a Scrum team is done early, can they pull stories planned for later Sprints?  If the story can be completed within the confines of the timebox, then absolutely yes!  Go for it!  However, the good Product Owners I have had the opportunity to work with are always looking to add more value to the release, not get things done early.  In many large organizations, you don’t get gold stars for getting done early, but you do get praise for getting more done than what was expected, i.e. improving productivity.

  What if you were a Product Owner and you could deliver this release plan?  In this release plan, the Product Owner has provided $24 of value, as opposed to the original $20 the stakeholders were expecting.

  

  How did the Product Owner do this?  Some user stories (blue boxes) were originally estimated to be large, but when implemented, were completed faster than anticipated.  There could be a variety of reasons why that is the case (which could be examined in a Retrospective), but the end result is the Team had extra capacity and Product Owner filled the gap with a new user story (green boxes) that could fit within the Sprint.  In my experience, these new user stories tend to be extremely valuable to the stakeholders and customers.  These are the user stories that just did not make it into the release and their inclusion now are special bonuses.  You make people happy with these stories.

  But why not pull stories earlier?  Can’t you just add all these bonus stories in the last Sprint?  You could and it is does not provide any extra value to pull work scheduled for Sprint 3 into Sprint 2.  Right now we have a gap in Sprint 2 looking for value.  If we pull an item from Sprint 3 we do not add to the total value provided by this Team for the release, we just conserve the amount of value the Team provides.

• Prioritization with Pugh

  Date: 2009.03.03 | Category: Collaboration, Design Excellence, Design for Six Sigma, Lean, Product Owner, Pugh Concept Selection | Response: 0

  I came across a recent blog entry where Brandon Carlson was discussing one technique he used to speed up the prioritization of Product Backlog items with Product Owners.  He describes the scene like this:

  “It was late July and I was sitting through yet another agonizing prioritization meeting. The sounds of debating product stakeholders filled the air, each weighing in on his or her pet feature’s relative merit, desperately trying to inch it toward the beginning of the development queue.”

  Reading further along in the article, you learn they solved this problem by scoring each feature (on a scale of 0 to 3) how well each feature met twenty-two key attributes from the perspective of both the business and the system.  The features that scored the highest were moved to the top of the prioritization queue and the ones which scored the lowest moved to the bottom.  What broke the logjam for them was having the ability to talk about the features using data and moving away from advocacy.

  What Brandon described is essentially Pugh Concept Selection – a Design for Six Sigma tool.  Bernie Thompson gives an excellent description on his blog of using a more “pure” application of Pugh to select between different cell phone plans.  Pugh was originally used to rank various design alternatives during Analyze, but again the Lean world has yet another mature tool that the Agile community can apply in our lightweight environments.

• Agile 2009 Submissions

  Date: 2009.01.22 | Category: Agile, Conferences, Design Excellence, Design for Six Sigma, Product Owner, Transitions | Response: 0

  Agile 2009 is accepting submissions.  This year I really feel I have something unique to bring to the larger Agile community, so I submitted two proposals - Product Design Tools for Agile Product Owners (on the Agile Product Management stage) and Charting the Agile Transition (on the Agile Adoption stage). Both build off of my recent work looking for the best tools from the Design for Six Sigma world to apply on Agile teams.  Please feel free to comment on the Agile 2009 website if you have any feedback.

• Without a Product Owner…

  Date: 2008.09.30 | Category: Product Owner, Scrum | Response: 0

  …you are not doing Scrum.  Recently, I had given a number of Scrum Lead classes to people interested in change.  Invariably when you get a bunch of people together who are dealing with the same organizational obstacles, they want to know why the organization has had so much difficulty in adopting Scrum.  After oberving a number of people who have attended my class apply Scrum, there is one consistent thread with all these Teams: no Product Owners.

  The Product Owner is responsible for executing on the Vision for the product and this is manifested through the Product Backlog – the central planning artifact in Scrum.  The Product Backlog is simply a list of all the functional and non-functional requirements for the product.  It is just all the stuff that needs to be done to release the product.  It can have lots of structure or very little; it is up to your environment and how much process ceremony your organization requires\is comfortable with.  The Product Owner is also the gatekeeper of what goes into the Product Backlog and their priorities.  As Ken Schwaber likes to say, and I am paraphrasing here, “The Product Owner is the single wringable neck”.

  So how does this relate to my observations?  Teams without Product Owners tend not to execute Scrum very well in a number of key ways:

  1. Missing the Product Backlog - Teams will naturally focus on the Sprint Backlog since that is their artifact.  IME, no Product Backlog usually means Teams will lurch from Sprint-to-Sprint with little focus on strategy or the “big picture” in mind.
  2. Low quality Sprint Reviews - Sprint Reviews will focus on completion of engineering tasks and not seen as a chance to gather meaningful feedback or re-prioritize.  I have seen a lot of “Atta boy”, back slapping reviews for completion of engineering tasks, but that is not the point of a Sprint Review.
  3. Cursory Sprint Planning - the Product Owner helps the Team understand the business context of the work the Team commits to.  When the missing Product Owner is missing, the Team will only use Sprint Planning to assign\sign-up for work and not discuss the goals for the product.
  4. Little thought about the Customer value - The Product Owner represents the Customer or gives voice to their needs.  Without this person at the table, literally & figuratively, Teams generally will not think about Customer value.
  5. Lack of balance between business & engineering - Normally, when there is no person on the Team whose job is to think about the business, the engineers will make all the decisions.  Do you really want your engineers making business decisions?

  Scrum is a very simple framework with clear roles.  Missing one of the key roles creates an imbalance in the system, a very serious imbalance.  I used to say that if you cannot find a Product Owner then maybe you should just cancel the project, i.e. if the organization cannot dedicate an individual to the product, then maybe the product is not that valuable to begin with (which is useful information to know).  I’ve changed my mind on that statement – maybe the work is still valuable, but Scrum is not the right vehicle for implementation.

  [Alternatively, you could also title this post "Without a Customer it is not XP" and all the same concepts apply - CEN]