As some of you1 might have realized, I am not writing any articles recently. I could state a lot of different reasons why (and some of them will be material for upcoming blog posts, by the way), but the main concrete reason for it is that I am spending most of my spare time creating my blog.
Whether the world needs another dev-tech-geeky blog made with Gatsby is highly arguable, but what is interesting for me is the process.
As opposed to my stereotypical pet project, I am trying to stick with a "business-like" process.
Design
Following what I learned from this awesome book, I have split the design of this product into layers, allowing me to get to the design phase with a lot of light already shed.
The document I produced can be found here.
As you can see, the document is far from the level of details discussed in the book and way more simplistic. Nonetheless, it turned out to be a huge productivity boost for me. With development (and music and other things within my comfort zone) it was crystal clear which kind of difference a proper plan could make. With design, for me, it was mindblowing.
The main focus during this phase has been forgetting I am a developer, forget technical constraints and try as hard as I could to think like a designer.
This led me to produce the design you can see here.
Owning the product
If shifting from the Developer to Designer has been hard, shifting from Developer to Product Owner is actually being even harder.
Although I thought I knew what to expect from a good user story, producing a good one is actually a completely different story (pun intended).
This is the board I am working with.
Why this post?
Well, as my own Product Owner I feel a bit at loss right now.
Maybe I am introducing too much boureaucracy in the process, but I really struggle in dividing my Developer self from my Product Owner self and this is exactly why I am asking for your help.
As developers, what would you like to see in a board like this? What is missing?
As product owners, can you suggest any good resource to learn how to write kickass stories and tickets?
Thank you all!
If you were still wondering, the code is still in a very bad shape, but as soon as I reach the
v0.0.1milestone, I will open source it.
1. It's actually a lot of you ❤ I never would have thought of having ~3.5k followers. Thanks to each and every one of you!
Top comments (6)
Hi Manuel. As you are producer and consumer of the stories, my advice is: think about what level of documentation do YOU really need? For example, what are the things you tend to forget easily? What are the things where you think it retrospect: a bit more planning would have helped? So: plan in time for your personal retrospective.
Thank you Bertil for this (:
My problem is exactly what you described: stories as they are right now are perfectly fine for me. However, the sole reason why this holds true is that the whole lot of hidden assumptions I make are shared between the producer and the consumer, so to speak.
Therefore, although my stories are serving the scope right now, I don't feel like I am being a good PO, as I am fairly sure no one besides me could understand my board.
This is the reason why I was after some good resources/frameworks/book to help me discover and clarify what I am assuming without even being aware of that
Since you‘re looking for recommendations, one good source for a lot of Product Management ideas is Roman Pichler. Here’s an example: romanpichler.com/romans-books/agil... One trait of a good product owner is that she’s doing what’s necessary depending on context. As long as you’re the only consumer, lots of implicit knowledge is fine. If you want to communicate with others, it’s a different story.
Thanks again Betril, I'll definitely look into this (:
The big promise, at least of the early agile movement was, to use a phrase attributed to Kent Beck, "healing the divide between development and business". This division had (and has) a negative impact, and therefore introducing it artifically in a "team of one" is to some extend, if not counterproductive, then at least pointless.
But, in your pursuit to deliberatly practice the business analyst/product owner/manager role, may I suggest to consider something that has become a bit of a lost art: writing up a software requirements specification in a more formal manner than "user stories". The story format originally was intended as a "promise for a future conversation" between people closely working together. A perferctly legitimate tool, albeit not as a replacement for a spec, and again a bit pointless in a team of one.
Here a few suggestions for skills/traits, that I could imagine, would make a product manager/business analyst, that many developers would be thrilled to work with:
If you’re a more technical Product Owner, or you have experience already in the role, there are some advanced areas I recommend Product Owners familiarize themselves with.
First of all, you should understand the Database Schema. If your website or application is more than just marketing information, it likely is powered by a relational database (like MySQL) or some other kind of database. Either way, it’s useful for the Product Owner to understand the structure of this database (often referred to as the “schema”). Understanding your database schema will have the following benefits:
If you are curious about this subject, I recommend reading the following article by my colleague Veronica Arreche: scalablepath.com/project-managemen... the article describes the skills any product owner should know to be successful.