small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

Being a Product Owner (PO) is a challenge that requires managing many aspects of the project, from understanding user needs to working with the development team. Especially in the MVP phases, it is worth balancing between what is necessary and what is unnecessary. However, there are essential tools that cost nothing, can improve the quality of your work, and make it much easier at the same time. In this article, we will look at several of the most critical tools, such as Jira, Miro and Chat GPT and how they helped me build digital products for German students and teachers.

#### Jira - Backlog and Task Board Management

Holly Jira, but I won't hide it - I like this tool. Maybe I'm old-fashioned, but I enjoy collaborating with teams in this particular tool. In the beginning, when building an MVP, the free version was completely sufficient for me! Why?

**Because I could flexibly manage the development plan (so-called timeline).**
Jira's timeline uses the epic level to build a delivery plan. At first, I managed to create just a few epics (including login/registration epics, building the basic architecture, etc.). Still, as development work progressed, I learned more and more and eventually built a 4-month development plan (for both applications - teacher and student). This was great because I made sure that the most important screens and functionalities for both end-users would be delivered, tested, and working. What's more, the timeline function revealed to me the fact that it's worth starting development work by building an architecture and backend to get ahead of the frontend a bit - thanks to this, we built interfaces based on a working system and endpoints.

**Because I could manage the backlog at the level of tasks and functions**
For me, the backlog is a sacred tool for every Product Owner. Properly organised, it supports the team, and introduces transparency and order instead of chaos. How did we organise it within the project?
- Backlog as a list - and looking at it from above - there were tasks with the most significant degree of detail, which were refactored and ready for development. At the bottom of the backlog were tasks at an early stage of their preparation.
- project scope in form of ticket types
as the development team progressed, the backlog was supplemented with backend tickets, stories, bugs or extra change requests from the CEO, CTO and other stakeholders.
- impact analysis - every time a new scope (sometimes more or less needed) was reported to the team - we tried to analyse its impact on the timeline and current priorities in the backlog. 

Keeping the nice and clean backlog is not easy, but it is necessary if the Product Owner expects the development team to operate efficiently at the delivery stage.
![blog-grafika 1_poprawiona (1).jpg](https://bitnoise-cms.btn.fyi/uploads/blog_grafika_1_poprawiona_1_b9f060cf50.jpg)



**Because I could order delivery on the Kanban board**

For me, the Kanban board is a must and a standard tool for tracking tasks and communicating with the team. A good task board reflects the team's current work and helps rather than hinders. Therefore, our Kanban board has evolved, as the needs reported by, among others, the team have grown. We started from the level of "TO DO, IN PROGRESS, DONE" columns and ended up... on the Mendeleev board ;)

![blog-grafika 2.jpg](https://bitnoise-cms.btn.fyi/uploads/blog_grafika_2_f5c7177481.jpg)

#### MIRO - visual collaboration and brainstorming

Miro is an interactive board that made it easier for me to visually present ideas and collaborate in real-time. Since our team worked entirely remotely, it was a challenge to work out solutions together. MIRO came to our aid. 
- Discovery and Research—If you red a previous article and learned what our Discovery phase looked like, you will know that all diagrams, User Personas, research results, Customer Journeys, and BMS were visualised and developed in MIRO.
- Workshops and Brainstorming: Miro was primarily used in my work to plan new features and their early visualisation. For example: gamification logic in the student and teacher application.  I visualised several scenarios for both end-users and carried out a requirements refinement, which was then used to create the final design and flows. In addition, our developers were also very keen to use it for their activities. For example, our Senior BE developer led Event Storming sessions in MIRO, thanks to which we learned the scope of necessary endpoints to prepare for the entire project.
- Retrospectives and presentations at review meetings - Miro is very rich in [templates](https://miro.com/templates/retrospective/), and I decided to transfer the process of conducting retrospectives and tracking actions from retro right there . My favorite retrospective is [the 4L method](https://miro.com/templates/4-ls-retrospective/) - and it's great that I didn't need any additional external tool to conduct it. 

![blog-grafika 3.jpg](https://bitnoise-cms.btn.fyi/uploads/blog_grafika_3_15848c3225.jpg)

Going further into experimenting with MIRO, I also decided to check the slide-show function - I used it to present the results of increments at a review meeting. But here, honestly? I would go for simpler tools like Google Presentations or Canva :)

#### ChatGPT - my personal advisor

Last but not least - ChatGPT. There is so much talk about genAI in products and projects, but I personally had a hard time getting used to this new reality. However, I managed to find a practical application for ChatGPT in my work as a Product Owner. What did I do with this tool?
- I planned meetings - the structure, flows, timeboxes and Agendas e.g Review Meetings. ChatGPT gave me also insights on how to engage programmers and stakeholders so we could conclude any assumptions and key points from discussions
- I looked for statistical data - ChatGPT came in handy during the discovery phase when I validated various data and statistics regarding the education industry in Germany. And so, among other things, I learned that the most popular age group among young people are children aged 6 to 14, and German schools have problems accessing wifi and working equipment. So I adjusted the strategies of both products (teacher and student) with additional assumptions: the age of end-users and the need to design the flow of the feedback and self-assessment process so that it meets its goals both remotely (on users' private devices) and at school (on, e.g. a school tablet).

#### Summary

Creating an MVP, which is really two products, requires managing many tasks and collaborating with various specialists. Although I built products from scratch and didn't need advanced tools to start with, without Miro, Jira and ChatuGPT, everything would have taken me longer, and the quality of my work as a Product Owner would have been questionable.

large_blog-Inclusion Digital Saga part. 2_cover_high.jpg

medium_blog-Inclusion Digital Saga part. 2_cover_high.jpg

small_blog-Inclusion Digital Saga part. 2_cover_high.jpg

thumbnail_blog-Inclusion Digital Saga part. 2_cover_high.jpg

blog-Inclusion Digital Saga part. 2_cover_high.jpg

Product Owner Tools: What to start with and how we dealt with this topic - the Inklusion Digital Saga part 2

I'm Luiza, the Head of Production at Bitnoise, a software development company. I also work as a development process consultant, focusing on team communication, project management tools, and efficiency. In this blog post, I will share some tips and tricks on how to organize your development process to keep it lean and efficient, using a real-world example from my collaboration with a London-based client. 

I will cover the importance of frequent delivery and client feedback, improved backlog management, and transparency in the development process. 

From this post, you will learn how my team and I delivered better, faster, and increased average sprint velocity by 35%.

#### **Background**
As a Head of Production and Project Manager, my main goal is to maximize the business value of projects. During my collaboration with clients, they expect three types of activities from me: 

- optimizing the development process, 

- speeding up delivery, 

- and generating savings.  


In this post, I will share how we achieved these goals with **a mobile front-end team** I collaborated with in the role of a Scrum Master. 

The company I worked with is an **international e-learning company with over 15 years of experience in the market**. Their solutions are used by millions of users worldwide. We were delivering for both iOS and Android platforms while trying out the Scrum approach for our development process.

#### **Measuring Success**
From what point did we start our reorganization process? From process metrics. What were they telling us? That we were inefficient and that we needed to understand why.  

The velocity chart displays the amount of work that was committed at the beginning of the sprint (gray bar) and completed at the end of the sprint (green bar). We used story points to measure the workload, and **chart no. 1** visualizes the velocity results from seven sprints before any of the process improvements were made. The measurements were taken in the middle of the year. Sprint velocity results suggested that the development process was not as effective as the company had expected, and only half of the planned tasks were eventually delivered (average CaC = 52%).  

**Chart no. 2** represents the sprint velocity results after 6 months of improvements. The measurements were taken at the end of the year, and **the effectiveness of the mobile team's delivery increased from 52% to 82%.**

**CaC = Completed / Commitment * 100%**

![ ](\uploads\blog-Boosting_efficiency_post01_73wsaA6BpWrq4vOUbw1Lzr.png)
![ ](\uploads\blog-Boosting_efficiency_post02_48PZie37iQTD0LuouVXtbJ.png)
For additional measurements of the development process effectiveness, we used the **burndown chart**. The burndown chart also represents the amount of work (in story points) that was completed in a sprint (2 weeks), but it also provides information about the history of story point completion and suggests any impediments in the development process.

Referring once again to the middle of the year period (so before any improvements were made) and **sprint no. 7** results, we noticed that our realization of the delivery plan was far from effective and perfect. The red line, instead of dropping down and getting closer to the gray line every day, was following horizontally. It meant that as a team, we were struggling with task delivery, and what's more, we were often adding new tasks to the sprint (shown as ups on the red line chart). We explored this situation further during the retrospective meeting and noticed that during **sprint no. 7**, we spent a lot of time waiting for requirement specifications and discussing excessively instead of focusing on development.

At the end of the year, after implementing all necessary process improvements, we measured **sprint no. 19** and **noticed a significant increase in our efficiency**. We were finally delivering and had minimized the gap between the realization and perfect plan lines. Although there were still ups on the red chart, indicating that we may have forgotten some tasks/requirements during sprint planning, we were able to present the increment by the end of the sprint.


![ ](\uploads\blog-Boosting_efficiency_post03_1xPIJErbzjEUjO2w6nSIYV.png)
![ ](\uploads\blog-Boosting_efficiency_post04_2ed0YhpBPBGulwyap3Bzs0.png)
So, what steps did we take to achieve this improvement in our software development process?

#### **Frequent delivery and client feedback**
One critical aspect of boosting mobile team efficiency was to implement frequent delivery and obtain regular client feedback. Our two-week development cycle always ended with a valuable increment, presented during a review meeting. **This allowed stakeholders to test the functionality and provide early feedback.** The review meeting included developers, the Product Owner, Scrum Master (the Scrum Team), internal clients such as business analysts and designers, and external clients. Moreover, together we discussed the backlog (requirements) and adjusted the plan for the next iteration (sprint).

For example, in a few sprints, we delivered an improved feature that allowed users to play, pause, skip, and seek the video. **The client's feedback after every iteration helped us identify some usability issues, which we addressed in the subsequent sprint.** This iterative approach ensured that the end product met the client's expectations, and we were able to deliver a feature that increased user engagement.

Regular retrospective meetings with the scrum team also helped us  identify areas for improvement. These meetings provided insights into  what went well and what didn't in our last iteration, offering valuable  information for planning the next steps.

Both review and retrospective meetings served as inputs for planning the next iteration, ensuring that the planning process also addressed necessary improvements and backlog adjustments.

These frequent feedback loops helped us minimize the risk of delivering unexpected results, set continuous process improvements, and foster better collaboration among team members.

#### **Improved backlog management**
However, at some point, we realized that poorly prepared requirements led to delays and inefficiencies in our development process. To address this issue, we took the following steps:       

- **Designated a single person (Product Owner) responsible for keeping the backlog up to date.** The Product Owner is the person who knows how the functionality should look and has the final say in its implementation. In our case, the Product Owner had a deep understanding of the client's industry and had been working with the client for over three years.     

- **Used JIRA as a single source of truth for the backlog.** This provided a central location for stakeholders to review the backlog during review meetings and for the technical team to discuss it during retrospectives and planning sessions.     

- **Organized the backlog as a list, with clear prioritization rules, issue types, and workload estimates (story points).** These steps helped us improve the quality of our requirements and streamline our development process.


Below, you will find the issue types that our team is currently using in Jira backlog:


![ ](\uploads\blog-Boosting_efficiency_post08_1oAJUGnZkAfJ8Knaqs1KiW.png)
Below, you can find the prioritization rules that our team is using in Jira backlog:

![ ](\uploads\blog-Boosting_efficiency_post07_tb5y0VLiEddmfgMgVQ4Pi.png)
- **Seek input from developers for technical analysis and involve designers and business analysts in refining requirements.** The Product Owner does not have all the knowledge about implementation details, so it's essential to get input from developers, designers, and business analysts when refining the requirements. Involving these team members in the refinement process eventually decreased the number of misunderstandings at the development stage. 

- **Ensure that all necessary requirements are finalized before the start of each sprint.** Having finalized requirements at the beginning of the sprint reduces uncertainty and ensures a smooth development process. Avoid changing these requirements at the implementation level.  


These improvements led to faster delivery, reduced time spent on unnecessary discussions, and increased transparency of what is going to be delivered next.

#### **Transparency and useful board flow**
Having a transparent and useful board flow is essential for an efficient development process. We customized our board flow to suit our team and sped up delivery. The board flow provides a visual representation of our development process, making it easier to track progress and identify bottlenecks.  

We have implemented **Work in Progress (WIP) limits** to quickly identify and address bottlenecks. As you can see in the example below, once we put three tickets in the "blocked" column, it becomes red. This means that developers should drop any ongoing work and quickly address issues with the Scrum Master or Product Owner so that they can support unblocking them. Why? Because without those tickets (requirements), we won't deliver what clients expect at the end of the sprint. Visualization is a vital practice in board management and supports fast delivery.  

Additionally, we used **burndown charts to visualize our sprint progress**, helping the team stay on track and adjust their efforts when needed. The burndown chart and up-to-date board became essential tools for our daily stand-up meetings, where we discussed our progress, identified any blockers, and ensured everyone was aligned with the sprint goals.

Below you can find the board rules set for our Mobile Frontend Team:


![ ](\uploads\blog-Boosting_efficiency_post05_5EDWNXN5NXg3eh0Nb97vmL.png)
#### **Conclusion**
In conclusion, by focusing on frequent delivery and client feedback, improved backlog management, transparency in the development process, fostering a collaborative culture, and measuring success, we were able to significantly boost the efficiency of our software development process. These improvements not only led to better quality products but also generated substantial savings for the client.  

Remember that every team is unique, and the methods we used might not be suitable for every situation. However, by continuously evaluating and refining your development process, you can unlock its full potential and achieve outstanding results.  

If you have any questions or suggestions, feel free to leave a comment below or reach out to me on social media. I'm always happy to help and share my experiences.

For the complete presentation and slides from the **Land on Moon event** (hubraum, Berlin), please check the video below.



Land on Moon #3

Land_on_Moon_3_-_Luiza_Kwiatek.mp4

small_blog-Boosting_efficiency_cover_high.png

thumbnail_blog-Boosting_efficiency_cover_high.png

blog-Boosting_efficiency_cover_high.png

Boosting the efficiency of software development processes: a real-world example

Quite recently, we delivered a project for one of our German clients, Inklusion Digital. Our task was to design and build an application for two groups of users: German teachers and students. Within the solutions provided, both groups had a common goal: to develop annual goals for students and verify their progress through feedback and self-reflection.

This is a fascinating example of an implementation in which we involved many different specialists; I had the pleasure of acting as the Product Owner of the entire idea. Today, I want to tell you the history of this whole project in several posts - so that you can understand the completed stages of the project, learn about the tools and practices... and learn from our mistakes.

We will start by analysing the discovery and design phases, allowing us to develop product design and UX tailored to users' needs.


In startups, the discovery and design phase is often overlooked and, as it later turns out, the most necessary. This stage of the product creation and development process aims to understand user problems, market needs, and technological possibilities. During this phase, the product team collects and analyses information to define the product's vision and determine its potential value and the risks associated with its implementation.

Suppose you are asking yourself what this is or are already answering this question by claiming that you do not see the relationship between the project's success and this phase. In that case, I will help you pragmatically out of this mistake.

According to [the latest research](https://www.nngroup.com/articles/discoveries-in-industry-revealed/) by Nielsen Norman Group and MIT:
- Product Discovery can help you lower the risk of failure by 75%.
- Teams using Product Discovery report 83% 𝗼𝗳 𝗽𝗿𝗼𝗱𝘂𝗰𝘁 𝘀𝘂𝗰𝗰𝗲𝘀𝘀.
- Discovery saves 50% of development rework time & 𝗰𝘂𝘁𝘀 𝗰𝗼𝘀𝘁𝘀 𝗯𝘆 33–50%. 

![blog-grafika 1 - discovery phase.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_1_discovery_phase_639acd94c3.jpg)


The above information guided us and convinced us that it is worth investing money into the discovery phase, as the results at the delivery and launch stages can be much more profitable. 
Before we started the design phase, we decided to work with the client in several weekly sprints to understand the needs of our end users (teachers and students) and their most significant pain points. How did we do it?

#### Customer Journey - process mapping

We set out to build a tool for the German education market to digitize the existing manual process of creating and managing students' annual goals. Using customer journey mapping, we analyzed the current process in German schools and identified the associated challenges. The results exceeded our expectations—it became clear that goal cards are often lost or forgotten, and their current format needs to be updated and made more appealing. As a result, students are less motivated to achieve their goals.

We definitely obtained tips and information that—as it now turns out—were the core of building basic functionalities in both applications.

We have placed the map and all information in MIRO.

#### User Personas - who is our end-user?

In parallel to building the Customer Journey, we decided to deepen our knowledge about our potential users - teachers and students in Germany. We started from the level: we want to make applications for all children and teachers in Germany. We concluded that the needs and requirements for using different applications are different and depend, among others, on the age of children/teachers, the type of school, and the education regulations of a given Bundesland. And this is how we defined our end-users (in an extensive summary :)):

- children and teenagers from various backgrounds, aged 10 to 16 (the most popular age group, we do not want to expose younger ones to technology), from secondary-level schools (business reasons for the client: gymnasium, Forderschule, Gesamtschule.. - the largest group of students)
- teachers - of different ages (challenge here!), and secondary-level schools (the same as above).
In addition to the specific characteristics of our users group - we have defined their key pain points, wishes and expectations in accordance to the build solutions. 

![blog-grafika 2 - personas.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_2_personas_26f5211ca0.jpg)
_Sample user personas template: https://miro.com/templates/personas/_


#### Business Model Canvas + User Stories
##### What do we want to build, and what are its chances of success?

After completing work on the customer journey and user personas, we felt ready to define the scope of our new product—digital applications for teachers and students that will improve the process of achieving school goals—together with the client.
We knew that: 
![blog-grafika 3.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_3_599cd991e0.jpg)


We started developing a [BMS](https://miro.com/templates/business-model-canvas/) and an Epic and User Stories outline. And we were like, wow - we create products tailored to the real needs of users! The Discovery Phase lasted about a month in total. After that, we started the design phase with full excitement. 

Those needs were converted into user stories with a MoSCoW prioritisation. We ended up with two scopes of products: one for teachers and a second for students. Suddenly, we realised that we were creating products that truly meet user needs. The Discovery Phase lasted about two weeks, and we moved on to the design phase, which took about a month.
Here, you can see the effects of the user stories slicing process: in the form of 2 maps in the Miro board.

![blog-grafika 4.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_4_1a511232de.jpg)
![blog-grafika 5.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_5_ac22b5d1a6.jpg)

The design was really smooth, primarily because of the great output from the discovery phase and the client’s involvement in the reviewing process. Teachers could expect a module as an add-on to the existing platform, and students would experience a separate app (independent of this platform). Teachers could, among other things, set annual goals together with students, leave feedback on progress, view results on an interactive chart, set a reward system and monitor students’ emotions. On the other hand, students carried out the self-assessment process, were recipients of rewards, collected points and shared their emotions. We have validated the design three times and, most of all - tested prototypes with teachers and students. We have received an enormous amount of input that has confirmed that we are ready for the development process.


Product Owner Tools: What to start with and how we dealt with this topic - the Inklusion Digital Saga part 2

Luiza

Boosting the efficiency of software development processes: a real-world example

Luiza

The discovery and design phase as the main component of product success - the Inklusion Digital Saga part 1

Luiza

GET IN TOUCH