Coming up with a metaphorical question like this does require good explanation… And I will. Let me describe two cases.
Case one, develop according to Scrum
In the first case, you are running your development according to scrum. As a product owner you have your end goal clearly defined. You chop up your end goal functionality in small pieces, so you have a complete set of stories for the product available. These stories are fed batch by batch to your development team.
You clearly explain for every story what the result should be and why this is needed. This way you build your product in small incremental steps. Every sprint your product is growing and you are getting closer to your envisioned end result. Also, you have your stories prioritized so the important parts are build first. Sounds like the way it should… right?
Case two, develop according to Scrum
In the second case, as a product owner you run your development according to scrum. You have your end goal clearly defined and only a set of stories available to cover the next two sprints. You clearly communicate with every story what the result should be and why that piece of functionality is needed and how it fits in your envisioned end goal. After every sprint you evaluate the result, learn from the result and start to extend your story-set till you again have the next two sprints covered. This way you are defining your product as you go, while you still keep the intended end goal clearly insight. Anything you learn can be directly translated into the sprint without throwing away all the preparation work that you have done. Sounds also like the way it should.. right?
Two ways to paint your product
Case one I see happening most of the time. And I understand that. It gives a clear framework and it provides management tangible result of the work of a Product Owner, even before development is started. In the end you need some proof that you are doing your job when you are in classic organizations. This way you can always show that it is not you if development fails somehow.
In second case you are lacking that “work proof” and you have to rely on “results proof”. For that you need to have the trust of the management. But the benefit of this way of working is that you learn while you are going forward without wasting any work that was done ahead of development. So less waste, more control, and more chance of hitting your goal.
Any new product is a journey into the unknown. Sure, you see an opportunity in the market, and sure, you have an idea on how to fulfil that opportunity. But everything is based upon interpretation, some vague market research on a focus group and gut feeling…
In the second case you can go back to your focus group, show the results of your sprint and take the feedback directly into stories for the next sprint without feeling the pain of throwing away work.
But as a Product Owner you need to be really close to your team in the second case. Observe every element during the sprint, be sharp in the sprint demo and directly understand the implications of every piece of functionality created.
So are you an artist?
Case one is painting by numbers.. The Bob Ross scenario. As a product owner you define the parts that the development team needs to color in fully upfront. Nice result for the people that are not capable of painting. You will not learn and you get the predicted product, but no guarantee on the predicted market result.
Case two makes you an artist. It is the Rembrandt scenario. You play with your lines, interact with your market and your team and learn from every stroke you make, discover elements you did not plan on. You are continues innovating and far better chance on achieving your desired market result.
I believe that the Product Owner needs to be a Rembrandt.
Ps: Special thanks to Bente Diemer who came up with the painter metaphor while doing research for UX in Scrum.
As also was posted on the Scrumalliance
A item about ever-reducing value of consecutive releases was lingering in my head, but it did not fully come out till I read this. It is a story about Rajen Sheth launching gmail in the enterprise space. He describes how he dealt with road mapping. Road mapping is one of the biggest pains for an Agile mind, since it forces you to plot an exact time line for releasing functionality over at least a year.
And anyone who learned about Agile, Scrum, or Lean start-up knows you are a fool if you try to do this. But the big problem is that the C-level boys and girls, for some reason, want it.
He correctly states that you should let them buy into the vision you have for a market, and show them how that vision is translated to functionality in the upcoming release. Also, all the features he stumbled into during conversations with customers and prospects were nicely identified and ranked. But then he made a mistake that may not hurt a company with unlimited resources but for sure can hurt your company (assuming your resources are limited).
He divided the most-wanted features into releases like:
- Current quarter
- Next quarter
- Next 12 months (e.g., second half 2013)
- Future (e.g., 2014 and beyond)
The problem of this approach is value.
Which items in general make it into the first current quarter? Exactly, the ones with the highest value. So automatically the important, hot, promising items that have just a little less value go into the “next quarter” release. If you talk to enough customers and prospects and have a creative mind and limited resources, your next quarter release is loaded before you have made your current quarter release. This is exactly how this terror thing called a road map got started!
So the major consequence of this approach is the reduced value of the next release, and the next, and the next, and the next . . . ending in only lame tweaks of existing features.
I would like to suggest (I am mild here since Rajen does have a kind of Guru status) to only commit to functionality in the current release. And make a ranking of the items for the next release without committing to it. Communicate your vision and goals continuously and deliver according to that vision. Keep it transparent and explain why items suddenly go on top.
If you have to commit to things past the current release, make sure you commit to the most limited number of items. Never have a fully planned release before you’ve even started working on a release. Ideally, you are committed content-wise no more than a few sprints ahead.
Reducing even more value!
Next to that, don’t let the customer’s wish list own your development. Product management is not about listening to your customer but about understanding your customer, so lists fed by current customers only will never bring you to new markets. This listening to the customer versus understanding your customer also is responsible for another source of reduced value. While you are building up value, your current customer will become more and more satisfied; as a result the items delivered on you feature list will become less and less valuable. You have saturated the needs of your customer. Actually, if you have reached that point it is time for a new vision, new segments, and new goals.
I know that it is very hard to put this in practice. It requires management and customers to buy into the product vision and goals and trust that you can deliver against it. And you have to deal with the C-level promises to this one special customer for that one special feature that is of no use to all your other customers. And that one is, most likely, the hardest. . . .
The 2nd pain of a product owner
Time for the second big pain of the product owner.. Starting a new product. As I stated in my previous post, the easiest thing of a PO is adding new functionality to an existing product. An existing product gives you a framework to work within.
This framework exists of the market, the user (and its needs) and the product ( a defined GUI structure, the technology stack, the database, etc.)
Everything is already there. All you and your team need to do is to extrapolate into a certain direction. You define the direction, but your team can easily follow, because the base you are coming from is know. Also, for the users it should be just a matter of extrapolating on the thing they used to do already. And of all the types of changes you can think of, extrapolating is the easiest.
But starting a new product takes away all or a big part of this framework. There are a massive number of things unclear. Not only the question of adoption is unclear. Typically that is the big thing of worry, but there are also loads other things unclear. Just sticking to the product many decisions have to be made. Gui design, application architecture, technology choices, etc. All these things are questions that need an answer.
Now you can spend months, or even years specing out each of these elements. Doing that is the perfect way of missing your window of opportunity for your new product. Take a different spin. Why do we like scrum? Well, for me, it is the perfect way to hit a target. A product has a market goal. Taking an “aim once” approach requires me to be a perfect archer. Scrum allows me to control the arrow in flight, so even if the target starts moving I can still hit it.
That is where most of us see the benefit of scrum, the commercial side. And of course, in the end that is what matters. But apply the same principle on technology choices, GUI design and all other elements.
I believe that you can also use scrum to do a fair part of the technology discovery and design. Create the most simple story (hardly any commercial value) that does forces the team to make choices on the area’s that are undefined. This will get the developers hands-on and understand the pains of certain choices. If it turns out that a certain choice was wrong, a single sprint was lost (not wasted since you have learned). Make sure that before you start these stories, it is clear that the goal is evaluate and learn from the uncertain elements in the system.
Another benefit of this is that these simple stories also will give you a starting point for your real user value stories. Because a new product in general has groundwork that needs to be there before the first stories that can be demo-ed are done.
I know.. this is a lean approach.
It has been a while since I wrote my last item. So it seems like the right moment to start about the pain of product ownership. Over the years I have been in product management I have been confronted with a number of Big pains. The big three are Bugs, New architecture and New product.
As a product manager I consider adding some functionality to an existing product the easiest part of my job. You may need to overhaul something to get it done, but in general it is just adding the thing you want to add and make sure it fits GUI schema and workflow of the user. But if you are a real product manager these things come by nature.
The first pain is really Bugs.. Your natural response on bugs is to fix them, and you should. But hold your horses. There is more. Bugs are the biggest enemy of your new functionality developments. Bugs cripple innovation. The cost of a bug exists out of:
- sad customer experience
- cost to fix
- cost of missing the opportunity to build new functionality
And the last one is really the major one. It is my believe that fixing a bug is softening the pain of a customer, but new functionality can really take away the pain. So you always try to deliver new functionality. But, of course, there is always a balance. (did I already mentioned that I hate nuances..)
If the number of bugs is growing, and regression bugs start to appear, there is something more you need to do. You need to know about the quality factors in your production. Is your product being coded according to all the quality standards? Are there unit tests, are there automated tests and run all these tests with checkins and builds? You need to know..
And over time you will discover that building a sustainable product can only be done based upon the best development standards. Even while you are a product manager, you should want and demand these standards. There is no excuse for not creating unit tests and automated test cases. And manual testing is not adding quality to a product. Quality is something that is transferred from one version to a next version.
Manage your bugs
How do you manage your bugs… I prefer not to.. :-) In my current role we have solved it in the following way. We have made a historical estimation of average time per two weeks spend on bugs. This average is the reserved bug budget in the sprint. Next we have given this budget to the Customer Care Manager and lead engineer in second line support team. These two deliver every two week their priorities. These priorities fill in the bug budget. Of course the content is overlooked by Product management. This allows product management to focus more on moving ahead and pulling the product forward. But at the same time every sprints delivers a stable balance between fixes and new functionality. But the best thing of all.. the hard choices of which bug is fixed in the next sprint is made by the people closest to the user that feels the pain. As a product manager you should be really careful with increasing the bug budget.. in general there is no reason to do that. In fact, it should go down.
And for the one that wonders.. you should not fix every bug. There a loads of bugs that simply do not get through the cost-benefit equation. But that could be a subject on itself again.
Next blog will be on the second biggest pain of a product manager.
Everything you hear about scrum will tell a story about better and faster software delivery, higher quality and more happy employees… But what does this mean for your business. Sure, quality is nice, faster delivery is good, and we all don’t mind working with motivated people. But from a business perspective you need more benefits.
Software development is about investment. Building new functionality is an investment that needs to be paid back in sales. These investments are big. Imagine a modest 20 developers team building functionality during the course of half a year. Let’s take a simple approach to this case for BtoB environment. In many countries this means a 1 million USD investment. Doing this in a traditional waterfall way will have the following symptoms:
- Sales is very reluctant in selling during the development phase. History has proven that products are delivered late, so sales is careful.
- Tangible product only becomes visible close to the end of the development, and only then can be reviewed by customers.
- Finished product always require post release changes to make it really fit for the market.
The investment is invested as a single shot. You can aim once for your market and that shot has to be spot on. Any change requires additional development investment after release to make it spot on.
Your investment according to scrum
Take the same scenario according to the scrum method. Developing based upon 2 weeks sprints, and based upon completed (manuals/tested/ training) functionality during these sprints. This will have the following symptoms:
- One month into the development of product the first functionality of the product can be demo-ed to customers, even a manual of the completed parts of the product can be shown.
- Feedback of customers can be fed back into development and adjust the development already after approx. 1 month into development.
- Due to the ability of showing tangible product, sales can start already after that first month
- Finished product has been widely exposed to customers and users, and is spot-on developed. Additional developments are extensions.
Let’s try to capture this. You could think of something that is called Product Maturity. Maturity is something that will grow as product changes are based upon exposure to users. The more a product is exposed and the more changes are resulting from that, the more mature the product becomes. Source of the change can be misalignment of product functionality but also evolution of users and markets (competition) or later discovered opportunities. And, of course, a more matured product has a better chance on higher turnover.
Let’s try to capture this is some extremely simplified graphs (and even that is an understatement).
First the waterfall one. Maturity grows in steps and sales starts at the end of the first development step, so close to 6 months into the process. The graph above already shows 2 releases. Typically in waterfal these are many months apart. The second release is in general used to correct failures in market alignment and quality.
Needless to say that the scrum method will provide a quicker return on the investment made. My guess that this will be at least 30% faster (very pessimistic estimation).
But there are a number of other advantages with regards to the investment made:
- Adjust product very early in the process to the market
- Ability to cancel a project in a very early phase based upon realistic customer feedback
- Respond during the development process to competition
Using waterfall you are always at least a year behind on your competition. This is valid even for small functional elements, since waterfall tend to result in one or maximum 2 releases a year. So you could say that you need Scrum to get agility in your business.
I know that in real live there are many variables that will change these graph, but there will be no situation where investments are earned back faster using waterfal. But if we simplify one situation, we also have to simplify the other.
In the past few years I have been implementing scrum from scratch twice. This is the reason why I have not been writing too much lately. Too busy getting scrum going. Both times it turned out that there was not much resistance or big hurdles. Both times the teams had to turn around from vague waterfall approach.
This makes me wonder. Why are there no major battles? Until tonight I could not really give an answer to that. But at a scrum meeting I had the pleasure to talk with an development manager of a big insurance company explaining me his difficulties of implementing Scrum from out of development while product managers did not buy in. That was pain… While I am thinking about tuning after 5 sprints, he was struggling to get requirements discussed a year after introduction. He is a long way from his hyper performing team goal. And I am not even taking the culture of the Insurance business in account here.
So, I guess, the difference is the support or even drive from out of Product Management. Of course without sitting on the chair of the Development Manager or Scrum Master. But why does that make such a difference? I think you have to look at the traditional role of the Product Manager to find the answer.
Don’t be evil…
For the average development department the product manager is evil. It is the guy that want the impossible functional, in a unrealistic timeframe. And since everything is put into a 100 page requirements doc, these cannot be discussed anymore. It has been signed off, we can’t change it!
When your Product Manager turns into a product owner the role changes completely. Let’s start at the requirements. No more 100 pages of requirements, but stories. And since stories are invitations to discussion suddenly the requirements are things an entire team can start thinking about. You have a platform that involves the developers in creating a solution. They are not building the solution, they are now part of coming up with a solution.
Another element is the fact that you deliver functionality every sprint. Due to the fact that each sprint you want to build value, every sprint demo the developers will show things that are relevant an tangible. It suddenly makes clear that what these guys are doing makes sense, that they are actually building value.
There is no developer on this world that does not want this. If Product Management supports transition to Scrum, you have won halve of the battle.. or maybe there was no battle at all, you just made a transition. If a team is confronted with an involved Product Owner, working as a developer becomes fun.
I am sure that the role of Product Owner can make the difference in making your transition a success. Also I believe that you rather should be a Product Owner then a Product manager. Since it gives you full control on creating successful products, instead of successful requirement documents.
Like many Product Owners I struggle with writing stories, or to be more accurate, I struggle with the acceptance criteria of stories. In an earlier post I tried to make a point of not writing great stories. Perfect stories will reduce the number of questions, and questions are the perfect measure to determine if someone understands what you want (you then achieve documentation over communication). Nevertheless, I started digging into the acceptance criteria again. Just to understand what others are saying about it.
Adding no information
The story example above was the first one I found. And apparently they did read my previous posts, since it hold loads of errors. J The three acceptance criteria listed are really not acceptance criteria from my point of view. The first one, providing a valid id and password is a 100% redundant sentence. It adds no information at all to the original story, and actually covers the happy scenario of this story. The second and third are equally redundant. Yes, we now know we have to create an error, but should case 2 and case 3 provide an identical error? Or should case to make a difference between wrong id and a wrong password? This would typically be covered in a separate story.
So, on the above Story the acceptance criteria example only results in a product owner that looks like a fool. And it is very easy to look like a fool in front of developers.
Another example can be found at http://www.boostagile.com/blog/user-stories-part-2-acceptance-criteria
As a user of the library catalogue, I want advanced search options on the front page so that I can quickly and easily refine my search.
The acceptance criteria are written in simple language that the customer would use, just like the user story. For the example above, the acceptance criteria could include:
- I can limit the search by format/type.
- I can delineate the search by date range.
- I can limit the search to publisher information such as title, author, subject, place, publisher and call number.
- I can restrict the search to a particular website/catalogue, collection.
- I can find advanced search options – advanced search options are carried through as filters to search results page.
- I can filter by availability.
Here the acceptance criteria are abused to add more sub-functionality to the story. So this story actually contains 7 stories. And the top story should be an epic. Each of the above should be split out towards separate stories.
These are the kind of stories that end up with massive number of storypoints estimations. However nice it seems, the above is really a bad example of what a story should be.
Finding a way with waterfall habits
A third nice example can be found at: http://dannorth.net/whats-in-a-story/
Acceptance Criteria are defined as scenarios:
As an Account Holder
I want to withdraw cash from an ATM
So that I can get money when the bank is closed
Scenario 1: Account has sufficient funds
Given the account balance is \$100
And the card is valid
And the machine contains enough money
When the Account Holder requests \$20
Then the ATM should dispense \$20
And the account balance should be \$80
And the card should be returned
This is an interesting approach. Reading the story above it tells the developers that they should create an ATM that withdraws the amounts it dispenses from the account balance. These kind of stories are painful left overs of the waterfall age. Those were the days that ‘if it was not written, you are not building it’. As a result you ended up with thousands of absurd scenario’s covering variations of the above. While I believe that taking the scenario approach is right, don’t write out scenarios like the reader is a mental disturbed. Also, acceptance criteria should fit on the back of the sticky note. A final argument in this is that a tester’s job is not to test functionality against scenario’s you write for them.
Concluding I see a number of things in the acceptance criteria:
- Totally useless information that makes you look like a fool
- Test cases that tells your, very well educated, tester how to do his work.
- Sub stories, that should be covered as a separate story
- Waterfall leftovers aka cover your ass descriptions. Only there to protect you from people blaming you.
Acceptance criteria can be useful. But I am sure that they are not, if they can be categorized as one of the above 4 categories . Very often you see that they are created as a kind of habit coming from the waterfall age and the misbelieve that you actually can develop functionality based upon a single line and sensible people in your team.
Scrum is based upon a vocal handover of stories. So in the sprint planning and in estimation sessions, the product owner ‘presents’ the stories. This is an essential part of scrum, since it is the only way to convey understanding. Doing this completely removes the need for ice waterfall age kind of specifications.
I know I cannot criticize others without giving my own view on it. Using one of the above used examples:
As a user of the library catalogue, I want advanced search options, using an including or excluding date range, on the front page so that I can quickly and easily refine my search
- Dates manually entered is according to the international ISO date format (ISO 8601)
- Dates entered via date picker tool should also be displayed according to the official format
No idea what application this would be for, but I do like to hear of my readers if you can come up with more acceptance criteria that make sense. So fire away!