Archive

Category Archives for "Software Development"

Software Development Methods & Tools

Software development is more than writing code. Software quality, clean code, agility, DevOps etc. require the right mindset and methodologies to create awesome software.

Here, I will share with you the software development methodologies that I learned during my career. For example, you will learn about fixing bugs efficiently, valuable attitudes in a Scrum team and many more…

7 Tips to Create a Product Roadmap from the Backlog

the Product Roadmap


I think you will agree with me when I tell you…

 

A product roadmap is essential to explain your product strategy to your stakeholders.

 

Nevertheless, it is not that easy for new product owners to create a product roadmap from the backlog.

 

When I started as a product owner, I had the same problem. First of all, I didn't understand the value of a roadmap. Second, I wasn't able to create one out of a huge backlog.


In my first year, I learned how to create a product roadmap from the backlog. For sure, it took me some time to solve the roadmap riddle but today I am able to help my colleagues if they struggle to create a product roadmap from the backlog. 


In this blog post, I summarized 7 essential tips which will help you to clean the dust from your backlog and come up with a great roadmap. So check it out!

1

Tip #1: Change is permanent

My most important learning was to accept that change is permanent. It even applies to a long-term roadmap.


When I started as a product owner, my relationship to roadmaps wasn't good. We were doing Scrum and focused on our sprint plans. I didn't see a need in creating a roadmap as our priorities anyway changed between two sprints.


This didn't work well with my stakeholders as they request to provide them a roadmap with clear commitments.


At on point, I just accepted the fact that it is natural that our priorities change. I challenged myself by creating a roadmap, knowing that it will change.


In fact, this helped me to make the priorities of my stakeholders transparent. In addition, your team will work more effectively as the roadmap provides them with a clear direction.

2

Tip #2: Clean up your backlog

Simplicity - the art of maximizing the amount of work not done - is essential. - Agile Manifesto

Sometimes doing less is the better solution. In my case, I got overwhelmed by a huge backlog. Including overall 150 user stories, I was not able to create a product roadmap from the backlog. 

For sure it took some time to handle this and one of the most important things was to reject some of those stories.


Therefore, I want to outline some cases where you should think about rejecting the story:


  • The person who requested the user story left the organization.
  • The user story is already 2 - 3 years old. 
  • The story is an unspecific improvement story, like "refactor the GUI".

In all these cases, it is totally okay to question the business value of the user story.


In my opinion, you shouldn't worry about offending somebody by rejecting a user story. If somebody complains that you declined their user story, it is already a good indication that there might be a business value.


3

Tip #3: Clarify your product vision

The disadvantage of focusing on features too much, is that there are always too many features that would add value, therefore creating a lack of focus on the vision and goals. - Robbin Schurrmann

A product vision is more than a fancy slogan. It provides you the right direction for your product. 


One tool for this is the Product Vision Board by Roman Pichler. With the help of this template, you can work on your product vision step by step. Filling out the product vision board challenges you to think about your customers and their needs. Furthermore, you need to describe how your product satisfies the needs and your business model (or business goals).


Hint: If you are struggling to fill out the board, you can also start documenting the current state of your product. Afterwards, you will feel much more comfortable about adding your vision.


Check out this example for some inspiration:

After defining your product vision, creating a product roadmap will feel much easier. Define the steps to achieve your vision and consider your backlog items.

4

Tip #4: Cluster the user stories

If you are dealing with a huge amount of user stories, creating clusters of user stories can help you to reduce the complexity. 


Either you can group the items according to the affected features or assign them to a specific customer segment. 


Afterwards, you can try to identify one or more key stakeholders or users. Talking to them will help you to raise your understanding about their needs. 


Another way to visualize the value of user stories is the Kano model: 

The Kano model helps you to categorize user stories in excitement, performance, and basic features. I always try to keep in mind:


  • One excitement feature can make your customers buy your product.
  • Performance features differentiate yourself from your competitors
  • Missing basic features can be a show stopper (but don't have to). 


Any of these clusters could be reasonable milestones for your product roadmap.

5

Tip #5: Define your release schedule

Defining a "strict" release schedule can give you a great basis for creating a roadmap. If you know when you will release your product, the basis for your roadmap is ready.


In the following infographic, I summarized how detailed I am planning in relation to the time.

Infographics - How to create a release plan

6

Tip #6: Don't prioritize, rank it!

In my discussion with different stakeholders and key users I recognized one flaw in the communication with my stakeholders:


Stakeholders often give a high priority to multiple things.


I am 100 percent sure you will end up in the situation where your stakeholders will request multiple things at the same time. If you ask them for a priority they will tell you 2 - 3 tasks that are the "high priority tasks".


One trick I learned about this to ask for a ranks instead of priorities. 


If you want to get shit done, multi-tasking isn't a good idea.


The problem is that people tend to prioritize in three levels: High, medium and low priority. Instead, a ranking defines a clear sequence.


If you want to read more about helping your stakeholders to rank their requests, check out my blog post about Where agile estimation fails: Involving stakeholders to prioritize user stories.

7

Tip #7: Get feedback about your roadmap

Last but not least, getting feedback about your roadmap is essential. The point is: If you are dealing with many stakeholders there isn't a perfect roadmap. Instead, the roadmap facilitates the discussion about your product strategy.


If you are struggling to create a product roadmap from the backlog, it is important that you realize that having no roadmap is no alternative. 


Ask your colleagues, team members and stakeholders for feedback.

Are you just starting as a product owner? 

I can also recommend you to read the article Tips for starting Product Owners by Robbin Schuurmann, which inspired me to write this post.

And if you liked this post, you should check out the other post on my blog. For example, there is one about 8 skills every software engineer needs in a Scrum team.

1

Where agile estimation fails: Involving stakeholders to prioritize user stories

Involving stakeholders to prioritize user stories is important but difficult at the same time.

Stakeholder Management

In this article, I want to share with you a technique that helped me during a workshop to overcome huge differences between my stakeholders. I call it the Three Factor Prioritization and it helped me to involve my stakeholders to prioritize user stories. All in all, it helped my customers to understand each other’s demands and agree on a ranking. In my opinion, involving stakeholders in user story prioritization always pays off as it provides me with a better understanding of their problems.

On the other side, it is hard to come to a conclusion involving many stakeholders. Nevertheless, I felt that mine was quite useful compared to other prioritization techniques like:

The Workshop

Let’s start with the beginning…

In an old-fashioned way, we invited our stakeholders to a workshop spread over 4 days. Our two main goals were to understand and prioritize their needs. Obviously, creating a roadmap for the management was also part of this <img draggable= 

Our workshop consisted of three parts:

In the first part, we focussed on knowledge sharing and user story discovery. In addition, we provided training to them about our existing application.

Second, we had to prioritize their use cases to come up with a roadmap after the workshop.

In the end, my team and I groomed and estimated the user stories to transform the ranking into reasonable product increments/milestones to come up with a rough roadmap.

Where agile estimation fails

The second part of the workshop didn’t go as expected.

Initially, we planned 2 hours for the prioritization session and asked the product engineers to prioritize their use cases themselves. After 5 to 10 minutes, all three came up with different rankings. 20 minutes into the meeting we were stuck in useless discussions. Two of the four stakeholders had completely different first priorities.

In this situation, creating a ranked backlog of user stories for their needs was not possible.

The participants did not share a common understanding.

Therefore, I had to come up with a different approach to prioritize their use cases.

Three-factor Prioritization

Faced with the problem, it came into my mind that we could use dot voting. After a short time, I realized this doesn’t work. With “only” four stakeholders involved, we weren’t enough people to use it.For this reason, I came up with the idea to take a mathematical approach and let everybody agree on a score for each user story.

The trick here was to go a little bit into detail. They were not able to find a common rank/score for each user story before.

 

Nevertheless, they shared similar concerns about my product anyway. Therefore I transformed their three biggest concerns into scoring categories:

 

 Urgency

What happens if we don’t have this feature? Are the users unable to operate their business if we don’t have? In my opinion, this is comparable to the basic feature in the Kano model.

Usage Frequency

How many users will use this feature? Will they use it on a regular basis, e.g. every day.?

Reliability

Are there any legal or product compliance concern if this feature is not there? If those concerns are high, the score needs to be high here. (If you aren’t working for a big company and don’t have those concern, feel free to omit this category)

Estimating user stories

In short, all stakeholders had to agree on a single score per user story and category.

 

Actually, I think this is the trick in this whole thing 🙂

If they agree on the specific topics, they won’t complain about the overall ranking. In the end, it produces the compromise we are looking for.

 

To keep it simple we restricted us to three estimates:

1 = low

2 = medium

3 = high

 

Limited estimation values avoided discussions about each category. On the downside, this ended with a high density of user stories around a score between 5 and 7.

 

Hint: For up to 15 user stories this was ok. If you need to rank more than 15 user stories allow a wider range can be helpful.

The Results

Our first results looked like this:

Urgency

Frequency

Reliability

SCORE

Story #1

3

3

3

9

Story #2

3

1

1

5

Story #3

2

1

2

5

Story #4

3

2

1

6

Story #5

3

1

2

6

Story #6

3

3

3

9

Story #7

2

2

2

6

Story #8

2

1

1

4

Story #9

1

1

2

4

Compared to the beginning this wasn’t bad but we ended up with too many stories with the same priority. It wasn’t a ranked list.

As we didn’t want to start all over again, I asked the participants to suggest weights for each category reduce the density of the list.

As a result, we provided a weight to the last category “Reliability”.

Now, the list looked like this:

Urgency

Frequency

Reliability (x2)

SCORE

Story #1

3

3

3

12

Story #2

3

1

1

6

Story #3

2

1

2

7

Story #4

3

2

1

7

Story #5

3

1

2

8

Story #6

3

3

3

12

Story #7

2

2

2

8

Story #8

2

1

1

5

Story #9

1

1

2

6

Or as a ranked list:

Urgency

Frequency

Reliability (x2)

SCORE

Story #1

3

3

3

12

Story #6

3

3

3

12

Story #7

2

2

2

8

Story #5

3

1

2

8

Story #4

3

2

1

7

Story #3

2

1

2

7

Story #2

3

1

1

6

Story #9

1

1

2

6

Story #8

2

1

1

5

This was the list all stakeholders agreed on. Later, I used this list to update our product backlog with these stories

Afterwards,  I updated our roadmap and everybody was happy (for now).

If you are dealing with stakeholders on a regular basis

Conclusions

Managing stakeholders can be difficult. In this workshop I learned a couple of things:

 

  • Be honest and open with your stakeholders.
  • Reflect on your progress and the method while time is running.
  • If people are stuck, changing the method/perspective is not a problem. Explain precisely why you want to change the method.
  • Shared understanding is always the starting point. There is no need to discuss if people don’t understand the other participants.

A really cool method to be open with your stakeholders is User Story Mapping. It is helpful to create a common understanding in a group and visualizes your product in detail. If you want to learn about User Story Mapping I would love you to check out my post about “How to do user story mapping to define a product increment

2

How to create better understanding for user stories

Backlog Grooming Meeting

Just recently, I read about shared understanding in Jeff Paton’s book “User Story Mapping”. A couple of days later, I asked myself: “How am I actually creating better understanding of user stories during backlog grooming meetings?” 


In my first days as a product owner, the main goal of backlog grooming meetings was to get as many stories estimated. Nowadays, we know much better. Instead, our focus is on quality grooming.


In this post, I want to describe which strategies help to prepare high-quality backlog grooming meetings. These things helped me to create a better understanding of user stories in the team.

How are we doing backlog grooming?


Let me quickly explain, how we are doing backlog grooming meetings in general:


We are having backlog grooming meetings every week. This helps us to stay ahead of our work.

As we are a distributed team all our meetings are virtual (voice-only). Hence, everybody needs to speak up if things aren’t clear. 


Estimating story points shows the biggest misunderstandings in the team. Nevertheless, this isn’t enough in many situations. Having the same estimates during pointing poker, doesn’t necessary lead to shared understanding.

How to improve shared understanding?


These are the 3 basic rules that my team and myself experienced to work well.

  • Groom less stories in detail than many stories quickly and with shallow understanding.
  • Explain the context of a story. Relate stories to user needs and your product vision or long term goals.
  • Define product releases to show your team when and how you would like to achieve your goals.

In different words.. 


You need to explain what a story is about, why it is important and when it should be done.

Do you like this article? Checkout my posts about 8 skills every software engineer needs in a Scrum team to get a real team player.

Image Reference: Pixabay

This article was posted originally on Medium as "Why shared understanding should be the goal of backlog grooming"


4

8 skills every software engineer needs in a Scrum team

What does mindset actually mean? Is my product owner angry at me? How can I become a better software engineer? In this blog post, I want to share with you the skills for software engineers I value as a product owner. Probably there are many more valuable attitudes out there but I wanted to collect these to remind my team and myself about the things that are important.

Commitment

Commitment is not about working extra hours. It is rather a good mixture of a “Can Do It” attitude and realistic estimates. Sometimes, to “give our best” is not enough. Don’t get me wrong on this! I love people that try hard but to recognize delays early we need to be more realistic than optimistic.

Robert C. Martin summarizes this very well in The Clean Coder. You can read his chapter on “How to say yes” here.

Collaboration

Although we try to prepare our stories as good as possible, clarification can be necessary. Take action if there is something to clarify. Try to contact a colleague and clarify your problem or find another way to get the answer you need.

Fail fast & cheap

Approach 1:

Break your work down to incremental steps e.g. according to your sprint goal. This helps to stay focussed and quickly get back to work after an interruption.

Approach 2:

Solve the most critical tasks first to identify problems early.

Readable Code

How much documentation is enough? Readable code is already a good start. In-code documentation for the most important API makes it easier for your peer-developers to understand the interfaces inside your product. Follow the KISS principle during the implementation. In addition, a SOLID software design makes writing clean code easier.

Automation

Keeping attention to repetitive tasks is important. DevOps is a huge buzzword today and every engineer should think about which things can be done faster or better by automation.

Innovation

Technology is evolving fast. If you want to be a top developer, you need to stay updated. Using existing libraries makes life easier. (Comment: I don’t know any example, where it was a waste of time to learn about new stuff in your field.  Nevertheless, I really struggle to see the value in this. I only have faith it pays off well!) 

Speak up

If something is not going well, give feedback (at latest in the retro) We want to work agile so everybody should get the change to learn something (even the product owner ;-))

Ownership

All these things will result in a high level of ownership. From my experience, treating software engineers just as coders is not the right approach. Apps easily get quite complex and therefore everybody in the team needs to feel responsible for the product. This reaches from reducing technical debt to making sure to provide value for the users

 

Do you wonder even more what a product owner is doing now?

Check out this video about what a product owner is doing. 🙂

If you want to read more about getting a crafty software engineer. I summarized five books for you that helped me to boost my career. Don’t miss out on them.

What I learned from Sadhguru about software development

“Attention is more important than focus”

This was Sadhguru‘s advice on “How to apply focus in our daily life?”. Surprisingly, in his opinion keeping our attention high is more important than being focused. He pointed out that attention will help us to explore the depth and details of humanity. Sounds quite esoterically, right?

What does this mean for software development?

Most of our time at work we try to follow the principle “Stop starting, start finishing” and I am a big advocate of it.

In contrast, Sadhguru’s answer reminded me that agility is about continuous learning.  Therefore, we need to observe the things around us and reflect our work.  Without continuous learning, agile software development isn’t agile at all.

If we solely focus on our goals, we will lose our ability to learn, grow and improve our software.

This is my learning from Sadhguru’s answer.

Do you struggle with doing the right things? My blog post about the Eisenhower Matrix provides you the essentials about decision making.

2

6 simple steps to analyze the root cause of software bugs

Software Bugs

As a software engineer, you probably agree with me…

Sometimes we need to find the root cause of software bugs and it takes forever.

Fixing this kind of bugs requires more than switching on the debugger. Instead, it requires a more structured approach.

In the automotive industry, 8D problem solving is used for root cause analysis. In this blog post, I summarized the essentials of this method to analyze the root cause of software bugs. Hence, I want to focus on the “dinosaur”-like bugs and how to find their root cause and solve them.

Root Cause Analysis Guideline

For my team, I reduced my experience with the 8D problem-solving method into six simple steps that helps us to find the root cause of software bugs easier and structured.my team and myself to solve our bugs more efficiently. Therefore, I explicitly combined the 8D approach with the Is/Is Not analysis and 5 Whys method.

Step #1: Bug Description

First, we need to collect the first information you received about the bug. The focus is on the problem analysis. Avoid thinking about technical solutions.

Step #2: Define the Problem Scope

In step 2, the problem description is extended. Clarify the following points:

  • How many users are affected?
  • How long was the bug undetected?
  • Is there a feasible workaround for the users?

If required, you can define short-term measures to reduce the impact of the bug. For example, inform your users or stakeholders about the bug.

Step #3: Is / Is Not Analysis

The Is / Is Not analysis is a very good method to complete your problem description. It summarizes all the details before analyzing the root cause of software bugs. Usually, bug reports have a very limited perspective. For this reason, developers (including myself) move from problem to solution thinking too quickly. This step helps you to keep your focus on the problem and analyze it from different perspectives.

With the Is / Is Not Analysis you will ask:

  • Where does the problem occur?
  • What causes the problem?
  • When does the problem occur?
  • Who detects the problem?

Step #4: 5 Whys Method

After creating a clear picture of the problem, we can start to analyze the root cause of the software bug using the 5 Whys method. Start with your problem description and ask multiple times “Why?” to figure out the cause for each problem. The basic theory behind this is that every cause has an effect. Here, the visible effect is the bug you want to fix. For difficult bugs, the root cause is likely hidden behind another cause. There will be a sequence of causes and their effects that finally produced the bug.

With the 5 Whys method, we want to track this sequence backward to find the root cause of the software bug. Therefore, the 5 Whys method is the core of this guideline.

Step #5: Root Cause Description

After we found the root cause, we need to write it done. It is very simple but it will help you to check again if there are any unclear points. Your colleagues need to understand it as well.

In addition, you should think about why the bug was not detected until now and how to avoid it in the future.

Step #6: Define measures

Define the measures to fix the problem. Keep your original problem description in mind as you don’t want to define countermeasures that are not targeting your problem with 100 %. From my experience, three measures are usually enough. Otherwise, you will not be able to finish all measures in a short time.

Download: The 6 step bug analysis workbook [FREE]

Ressources

8D problem solving

“Bullet Proof Debugging” – Simple Programmer

5 Whys Method

Is / Is Not Analysis

Root cause analysis template for software bugs

The 6 step root cause analysis template

The root cause analysis template will guide you through your root cause analysis using the Is / Is Not analysis and 5 Whys method. It helps you to structure your problem-solving sessions for software bugs.  These six chapters will guide you through the process of bug analysis:

1: Bug Description

2: Define the Problem Scope

3: Is / Is Not Analysis

4: 5 Whys Method

5: Root Cause Description

6: Define measures

The steps will help you to create a complete description of your problem and support you to find the actual solution to your problem.

If you are in doubt if this can help you, read the complete blog post with more details about the 6 steps.

 

Free Download

Sign up for my newsletter to get the root cause analysis template. It has everything you need to execute the 6 step bug analysis:

  • Essential questions to guide you through the 6 steps.
  • My Is / Is Not analysis
  • A very simple template of the 5x Whys method
  • Enough space for you to add your details…
  • .. and use it for all your difficult bugs.

 

1

Agile is Dead – Pragmatic Dave Thomas

Agile is dead!

Dave Thomas emphasizes in this video that the idea behind agility is continuous learning and being able to adapt to change in the future.

Keeping it simple, agility is about:

– Find out where you are.
– Take a small steps towards your goal.
– Adjust your understanding based on what you learned
– Repeat

It depends on you!

Devops, Scrum, Kanban, Continous Integration, Design Thinking and every other technique that is praised today can fit your needs. Depending on your problems, you need to decide how these topics fit your organization best. The key to successfully applying new concepts is that everybody involved has the right mindset.

If you want to know which attitudes I value in a Scrum team, I want to recommend to you this blog post about 8 skills every software engineer needs.

Find more Videos of the Week here.

 

Ressources:

Agile is dead – Dave Thomas (Video)

The Agile Manifesto

The real meaning of software quality

Software quality is more than clean code, flexible design or unit tests. Check out this video from Udacity. It explains the actual meaning of software quality.

In software what must… does not. Software quality is never urgent but important. My blog post about the Eisenhower Matrix will show you how to focus more on doing the important things instead of the urgent ones.

Check out more videos on the Software-has-bugs YouTube channel

Find more Videos of the Week here.

1

5 books to create a software development mindset

Books are a great source of inspiration for me. For this reason, I want to share with you the five books that were very important for my career. Most of the books are about software engineering but their lessons reach even further. They definitely formed the software development mindset I have today.

1. Cracking the Coding Interview  – Gayle Laakmann McDowell

During my master studies, this book helped me a lot to understand what skills software companies expect from a software developer. On one side, it summarizes the most important aspects of coding interviews. On the other side, it has much more exercises for you to train yourselves for coding interviews. After working with Cracking the Coding Interview for 2 months, I was able to pass my first coding interviews.

2. Clean Code – Robert C. Martin

Probably, one of the most frequently suggested books for software developers. Uncle Bob (Robert C. Martin) has provided great examples what makes the difference between good and excellent code. It is a great book to read at once or apply it chapter by chapter in your daily work.

3. The Clean Coder – Robert C. Martin

Compared to Clean Code its follow up The Clean Coder summarizes the essential aspects, behaviors, and methods every real software craftsman should know. After one year, I am still using it regularly to get back on track if I am struggling. The chapters on Saying Yes and Saying No helped me a lot to recognize conflicts about “agreed” timelines.

4. The Phoenix Project – Gene Kim

The Phoenix Project is a game changer. Before reading this book, I mostly focussed on the implementation of features and their technical perfection. In contrast to tight deadlines, this was hard to achieve. The Phoenix Project introduced me to the mindset of DevOps and helped me to reduce unplanned work in my Scrum team. In addition, it is easy to read. All the content is packed in a great epic that makes you feel understood. It mentions many difficult situations you may experience in your daily work.

5. Show your work! – Austin Kleon

Do you think your work is not recognized by your non-software colleagues or your boss? Show your work! is quick start on showing off a little to get recognized. I got it from one of my high school friends. Overall, its quintessence is that showing the way towards the result is as important as presenting the result itself.

These books really help you to boos your technical as well as communication skills. If you are working in a Scrum team these eight skills will help as well.