small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

After several months of work and the involvement of the entire team, the time has come to plan and **execute the release**. For many, this may be an exciting moment, but from a technical perspective, it is often accompanied by **stress**. So how can the entire process be planned so that next time, when asked, 'How's the **release** going?' you can respond, '**Don't worry; it's real ease**.'


In ideal circumstances, deploying an application for the first time can be relatively stress-free. We start with a 'clean slate' - we don’t have to worry about users who might encounter a bug because there simply aren't any yet. Of course, such a release still needs to be planned, but the team has significantly more room to make mistakes or test something in the target environment.

In our scenario, the situation was more complicated. For a long time, we have been working together on an existing platform for teachers in Germany to facilitate collaboration among them to best support students' development. The application was growing very intensively, continuously delivering new solutions and responding efficiently to the needs of its users. It turned out that this was not the end. The application fulfilled its purpose and facilitated teachers' work but needed more student elements. The next step was creating a smaller platform for students to observe their progress, track their goals, and earn rewards. At this point, we decided to expand and split the development team slightly to get to work. Team A was to continue the daily work on the teacher platform, while Team B was to start implementing the new student platform.


Thus, as we entered the final phase and began planning the release, we found ourselves in a rather unusual and difficult situation. Here are our conclusions about the steps that need to be taken to maximise the chances of a successful release.

#### Organisational Planning Phase


##### **Release Date**
First and foremost, the planned release date must be established. Sometimes, this date is dictated by the client or managers, but usually, it will be a time frame rather than a specific day. As the project nears completion, the team should be able to pinpoint a particular day for the official release. At this point, adding at least one extra day to the planned date is advisable to provide a buffer for any potential complications.

In our case, setting this date was more complex because while Team B was finishing the implementation of the new platform, Team A was continuously working on new features and conducting their releases. Therefore, we had to gather both teams and jointly decide on a moment that would allow Team A to complete and test the current phase of their work while also allowing Team B to deploy their module without blocking either side.

##### **Responsible Persons**
If you have yet to assign individuals for specific tasks permanently, this is also a good time to designate responsible persons. Our situation required significantly more coordination and inter-team communication, so outlining specific tasks and assigning individuals to them was crucial for the process to run as smoothly as possible. However, creating a task list will be helpful even in less complicated scenarios.

Remember that projects often include less experienced members. An organisation like this will clarify them and offer valuable learning opportunities.


##### **Attention to Details**
It's worth remembering to write down even the most minor things that come to mind because as the planned release date approaches, more things will demand our attention, causing us to forget details that seemed evident during the planning stage. Keep in mind the detailed documentation related to the deployment process, such as:
- Creating or updating the README file,
- Updating user documentation: FAQs, release notes, instructions, and guides,
- Ensuring all licenses, cookies, and legal information are up to date

#### **Technical To-Do:**

Before initiating the deployment of your application, it's crucial to address several technical tasks to ensure a smooth and successful release. These steps help minimise the risk of disruptions and ensure your application functions as expected in the production environment. Here’s a comprehensive checklist of technical tasks to complete:












##### **Data Backup**

Data backup is a critical step in the deployment process, as it ensures that you have a reliable way to recover your application and its associated data in case something goes wrong. 

This is especially important when deploying an application that automatically performs database schema migrations at the time of deployment.

##### **Ensuring All Dependencies Are in Place**
Our application may be another piece of the puzzle in more complex systems that are dependent on other services. These may sometimes include a database, a queue system, or a data encryption service. We must ensure that all configuration variables are correctly set and that these systems can seamlessly integrate with our application.

##### **Create a Staging Environment**
It's crucial to thoroughly test the entire configuration in an environment that closely mirrors our production environment. This allows us to catch critical errors during internal testing stages.

##### **Deploy to Production Early**
When creating a new system, we can sometimes deploy our application to production ahead of the official release date. This was precisely the case for us. We deployed the new services a week earlier and tested their full functionality. Meanwhile, the integration parts in existing services were hidden using a feature flag. Nothing changed from the users' perspective, but this allowed us to begin testing in production by enabling the feature flag for specific users. Thus, the final release was simply disabling the feature flag for everyone.

##### **Conduct Alpha and Beta Testing**
Alpha tests are internal tests, while beta tests are conducted externally with a limited group of users. This approach not only helps us catch bugs but also allows us to gauge what our target users like or dislike. It also enables us to identify logical errors and verify our assumptions.

##### **Monitoring**
It is very important to maintain the health and performance of your application. Effective monitoring helps identify and address issues before they impact users or lead to significant downtime.
- Set up tools to monitor the performance of the application and servers.
- Establish alert thresholds to respond quickly to issues.

##### **Contingency Plan**
A contingency plan is a crucial component of your deployment strategy, designed to ensure that you can respond effectively to unexpected issues and minimise disruption if things don’t go as planned. 
- Prepare a plan to revert the deployment in case of critical issues.
- Team on Stand-by: Ensure key personnel are available and ready to act in case of an emergency.


In our case, this was an essential part. We needed the best contingency plan as our release affected real users. Any issues that might have happened during the release needed to be easily reverted or at least quickly hidden. 

#### Conclusion 

Successfully planning and executing a release requires careful consideration and thorough preparation. By addressing both organisational and technical aspects, you can significantly reduce the risk of complications and ensure a smoother transition to production.
 
 
In our case, the complexity of deploying a new student platform alongside ongoing work on an existing teacher platform highlighted the importance of detailed planning. Establishing a clear release date, designating responsible individuals, and paying attention to every detail were crucial steps. Moreover, implementing data backup procedures, effective monitoring, and a comprehensive contingency plan were key to managing potential issues and ensuring a successful release.

Ultimately, a well-executed release meets project goals and sets the stage for future success. By learning from each release and refining your processes, you can continue to improve and achieve greater ease in future deployments. With the proper preparation and mindset, you’ll be well-equipped to handle the challenges of any release and turn potential stress into a seamless experience.

large_blog-Inclusion Digital Saga part. 6_cover_high (1).jpg

medium_blog-Inclusion Digital Saga part. 6_cover_high (1).jpg

small_blog-Inclusion Digital Saga part. 6_cover_high (1).jpg

thumbnail_blog-Inclusion Digital Saga part. 6_cover_high (1).jpg

blog-Inclusion Digital Saga part. 6_cover_high (1).jpg

Release or Real ease  - the Inklusion Digital Saga part 6

Frontend Engineering

UX/UI Design

Research & Discovery

AI For Your Business

Services

Case Studies

Career

About us

Blog

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.


large_blog-Inclusion Digital Saga part. 1 _cover_high.jpg

medium_blog-Inclusion Digital Saga part. 1 _cover_high.jpg

small_blog-Inclusion Digital Saga part. 1 _cover_high.jpg

thumbnail_blog-Inclusion Digital Saga part. 1 _cover_high.jpg

blog-Inclusion Digital Saga part. 1 _cover_high.jpg

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

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

Going from the design phase to the delivery phase always brings excitement but undoubtedly doubt. Project Managers and Product Owners wonder: What functionalities should we start production with? How can we stay within budget? And finally, what methodology should we choose so as not to overdo it and deliver?

#### Soft start 
We have engaged three specialists for the project - a backend developer, a frontend developer and a tester. When we started, we knew that:
- we want to build an MVP in the form of an application for students and an additional module attached to the main product for teachers,
- we have obvious expectations, a well-designed design and support from our stakeholders (CTO, CEO, Marketing Team, sales team, German teachers),
- we are aiming for a production release in March 2024 (at that time, we had the end of December 2023),
- during the ongoing work, we have to include tests with teachers and students to obtain valuable feedback,
- we have to ensure the scalability of the product and remember the assumptions in the Discovery phase (i.e. who we are doing it for, why, what long-term product strategy, etc. - I presented the conclusions in this article: [click](https://www.bitnoise.pl/blog/the-discovery-and-design-phase-as-the-main-component-of-product-success-the-inklusion-digital-saga-part-1))

We started the development by:
- Setting up the infrastructure, building the architecture of the new student application,
- Integrating this application with the existing platform for teachers,
- working on the first endpoints of the login process (probably a classic of every startup - you start by logging in).

This soft start allowed for a smooth, gradual addition of the frontend programmer and QA. We had a week or two of spare backend work on the frontend at each project stage. Our QA specialist, on the other hand, divided his time between working on our MVP and the team working regularly on the educational platform for teachers. This is how it went for the following weeks of work.

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

#### Scrumban - was it worth going crazy like that?

In my career, I have implemented projects using many methodologies and frameworks, such as AgilePM, Scrum, Kanban, and staged/waterfall. Using them had its pros and cons. Due to the specifics of working for a client (including the lack of Scrum Master/Agile coach roles, the need to synchronise work and releases with a parallel development team) and a completely anticipated project (because there was a design, an available client) - I decided to try a delivery framework with an exciting name: Scrumban. How did it look for us?

_Firstly, abandoning cyclical sprints in favour of flexible releases_

Working in regular sprints was out of the question - among other things, due to the size of the team, we knew that it would simply be a management "overkill". For us, the moment of meeting with the client for a review and deciding on a release was a reasonably flexible statement based on "Okay - interactive, working things are starting to appear - we feel that we should collect feedback on this part". However, once we had a demo, it was really effective, interactive and valuable. Additionally, we had such meetings planned in our roadmap (although they were supposed to be shiftable), and we conducted the demo about four times in total.

_Secondly, the backlog and roadmap as the main sources of information_

As standard, as in most agile frameworks - we worked with a backlog and roadmap in Jira. At the beginning of development, we built the roadmap of both solutions (the application for students and the new module for teachers). We corrected it continuously, considering change requests or delays/accelerations. The backlog lived daily - supplemented with tasks, stories and bugs - which were released by the Product Owner to the Kanban board of functions at the right time.

_Thirdly, limiting team meetings to daily and refinement meetings_

Our team was small (but agile!), so we decided to limit the daily to 3 times a week. Due to the abandonment of cyclical sprints in favour of flexible releases, we also eliminated planning meetings - we focused on refinements with the client in written form (on the messenger) and the form of cyclical meetings (twice a week). Thanks to this, we kept the backlog and the roadmap up to date and prioritised, and production breaks did not happen to us.

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


#### Conclusions

To sum up, the delivery phase in this project was exceptionally dynamic and demanding, but our approach based on flexibility and adapting to the client's real needs brought the expected results. The most important thing is that we delivered the project in 4 months (we closed the development work in April) and managed to release both solutions in production in May (client's business issues). Focusing on a small, essential team: a Ui&UX designer, two programmers, one tester and a Product Owner minimised the costs for the client and helped us maintain agility. Giving up cyclical sprints in favour of flexible releases allowed us to better adjust the pace of work to the real needs of the project and the second parallel team. Thanks to this, we could respond more effectively to feedback and introduce changes smoothly and without downtime. Limiting meetings to a minimum allowed us to maintain high team productivity without unnecessary breaks in work. Soft start allowed savings in the project and conclusions from the discovery phase - to reduce the rework time by 50%.

Release or Real ease - the Inklusion Digital Saga part 6

Daria

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

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

Luiza

Scrumban and a small team to ensure high-quality project delivery - the Inklusion Digital Saga part 3

Luiza

GET IN TOUCH