Agile Product Owner Blog
Journey and random thoughts from an Agile Product Owner
Agile Principles – why do I care?
Jan 18th
Are you an Agile shop? Have you just been exposed to terms such as Scrum, daily scrums, Sprint/Iteration planning, Demo’s, retrospectives and more? Did you know about the 12 Agile Principles?
Back in 2006 we discussed the implementation plan at our shop and laid out the pros and cons of Agile. We wrote down the reasons why we should implement Agile and what we hoped to gain from it. From those early goals came our roll out plan and we did a great job checking back to it for the first year or so.
During an early 2009 Focus Group meeting with key individuals from each role on our Agile/Scrum teams we realized how important it was to continually remind ourselves about the 12 Agile Principles. You see, we hadn’t kept them as visible and transparent as things such as our Sprint Board, our Mid-Range Planning Board and even our 6-12 month project goals. The 12 Agile Principles had been “forgotten”.
Over the next few weeks I will take each principle and write about why you need to care about them. For those who haven’t seem them in awhile here they are for you review.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Story Points – do they really matter?
Nov 19th
There is so much talk about planning in Scrum. The basic questions are around how you handle your sizing of user stories. Also related is the discussion about how to handle situations where a story is sized but doesn’t get done in a Sprint. Do you carry the points over, resize and so on. Here are my thoughts from a post I made to the Scrum Alliance Google Group.
How complex are we really making this? It seems overcomplicated and takes away from some of the core reasons I find Scrum beneficial and useful.
As a Product Owner, I view the process as the following:
A) Request for a project is received
B) Initial “High-Level” User Stories are written
C) Team uses Poker Planning, t-shirt sizing (or for one of my teams animal sizing) to measure the relative size of the stories. We do this using a baseline story and ask, how complex, difficult, hard to know is this story compared to baseline story
D) I use the cost of the team (payroll, hardware, software, etc.) and the through-put (average velocity per Sprint) of the team to determine cost per point. This tells me estimated cost per sized story and therefore for the project
E) From experience (and in a post I made here most of you agreed), I multiply a buffer of 2-4 times the teams estimate and provide a cost range estimate for the project. The cost will be between $xxx,xxx (based on teams estimate) and $xxx,xxx (based on my multiplier).
If we move forward with the project then the user stories are broken down further and resized (1 high-level story might become 12 stories). If the cumulative cost of the 12 stories will impact your overall plan (timeline and cost), then be transparent immediately and share that information with your stakeholders.
Now to the question about how to handle story points when a story isn’t done by the end of the Sprint?
While it would be nice to hear and know what your best practice is regarding this question, how big of a deal is this really? As long as you are having a retrospective and you address and fix the issue of stories carrying from one sprint to the next, it won’t have that much of an impact on the average velocity and therefore doesn’t greatly impact the figures I use for planning. Just do what makes sense in your shop. If you don’t like it, talk about in your retro and hopefully you have enough freedom and self-managing permission that you can make the changes to fit your team and operation.
Role of a Product Owner? Hire from inside or outside?
Nov 11th
As Agile software development as a methodology is becoming increasingly popular so are questions about how to fill the role’s on a Scrum or Agile team. Here are the typical roles on a team:
1) Product Owner
2) Scrum Master (Project Manager)
3) Developer
4) Quality Assurance
Here is one source that attempts to describe the roles. While they take a decent stab their Product Owner description is off base. In a newsletter from Pragmaticsw.com they define the roles as the following:
- Product Owner – This is the person that identifies and prioritizes the features that will appear in a sprint. This is normally the CEO, CTO, or some other high level stakeholder that ultimately is responsible for shaping the roadmap of their product.
- Scrum Master – The Scrum Master is akin to the Proejct Manager in Waterfall environments, but does not manage the team deliverables at a micro level. Instead, this person is responsible for ensuring that the sprint stays on course, no new features are added to the sprint, code inspection, and ensuring everyone plays by the rules.
- The Team – Each team member is empowered and expected to self-manage themselves and to participate in all duties needed to deliver a feature. This includes analysis, design, coding, testing and documentation.
Given the Product Owner description above, how do you hire a Product Owner that is not a CEO, CTO or any other management level position?
One of the failures in the implementation of Agile is a Product Owner who is not 100% committed in time to the projects and the team. A Product Owner is part of the team in Agile and should be as available and engaged as the other team members. While this isn’t always possible, especially early in the implementation of Agile in your shop, this needs to be a goal and part of the implementation plan.
Roman Pichler writes on the Scrum Alliance website about the role that a Product Owner plays. The article talks about the importance of being engaged and in the drivers seat for the project at all times. This means a PO could have other responsibilities at a organization but their primary responsibility should be the team.
A Product Owner should have a deep understanding of software development, be well versed in Agile and have enough time to dedicate to the role and job as Product Owner. It is also good for the Product Owner to be versed in the business at hand and familiar with core business functions. The decision about hiring from inside or outside should be based on finding someone that fits the above criteria.
The Product Owner Ready Board
Nov 7th
A few months back I discovered a blog post that discussed the use of a Ready Board. The author, Serge Beaumont, lays out a well described argument for the importance of a Ready Board.
We do a great job in Agile focusing in on the function of the team. We write and learn in certification courses about not taking on a story in a Sprint until it is ready, not allowing changes to the story when in a Sprint and we define when a story should be considered done (complete). The absence of discussion about the process a Product Owner and in some cases a Business Analyst does to prepare a story is troubling. That process should be as clearly defined as the Sprint to Release cycle. Serge Beaumont does a good job touching on this as he talks about the Ready Board.
While the author, Serge, says that Agile has two stable ’states’, I’ll refer to them two stable ‘history’ moments. A story being “Ready” and a story being “Done”. Those two moments in the history of the story are indeed the only times they are stable.
To illustrate here are three images from Serge’s blog:
The image above represents the two ‘history’ moments in the life cycle of a Agile story. Most of our focus in Agile is between the Ready state and the Done state. That is when a story is committed to by the team for a Sprint, worked on, tested, and delivered as Done. Remember that Agile encourages, even demands, a story be “Potentially Shippable” when it is “Done”.
The above illustration of where the PO focuses and where the Team focuses is a great one. Keep this one in mind as you look at the following illustration. This is where your focus as Product Owner should be. If you are fortunate to have a Business Analyst on your team, they would be focused along with you as you get “New” stories and move them towards “Ready”.
Before I had the “Ready” board concept in mind it was easier getting focused in on the details and spreading time to thin between new stories coming in all the way through to a story being done. It is easy to get lost given the below.
A Product Owners responsibilities are varied and cover such areas as;
- Requirements gathering
- Developing user stories
- Communicating frequently with the business or client
- Analyzing importance and setting priority of user stories
- Being available to team in answering questions and providing clarification
- Planning for upcoming Sprints
- Planning for several future Sprints
- Negotiating with business or client and team
- Supporting team in their Sprint commitment
- Being familiar with technologies used by team
- Evaluating velocity and searching for new a better ways for team improve
- Being engaged and familiar with daily team issues
- Staying three steps ahead in all areas
One of the biggest challenges we face as Product Owners, outside of the job itself, is staying far enough back that you see the forest instead of the trees when looking at this list of 13. Stepping back far enough is critical to performing your core function as a Product Owner.
The Ready board is a perfect aide in ensuring you are able to stay far enough back from the detail of your project. In the life cycle of a story as it makes its way from creation through to being on production and used by the end user, your Ready board is one of the best tools for you as a Product Owner.
Enjoy and please comment.