Yaaay, I’ve finally reached the end of this series of posts!! Even though I read, studied, and practiced everything that my mentors recommended, plus the Professional Scrum Product Owner (PSPO I) training material…
I still feel not capable. And that is normal.
I compare it to my testing background:
until you are out there getting your hands dirty, learning from experience, reaching your goals, you won’t feel prepared and accomplished.
What I can offer you is a compilation of the advice that I received and treasured during my role transition:
In Agile, one of the most common approaches for capturing the user’s requirements is User Stories. They represent customer requirements in a card, leading to conversation and confirmation (Jeffries, 2001).
Let’s start by clarifying that anyone in an Agile team can write a user story. However, the product owner needs to make sure the user stories are actually necessary for the product and they have a prioritized backlog. To make sure this happens, the PO needs to communicate regularly with the team and they discuss the stories together. User stories should get written collaboratively during the product backlog grooming/refinement sessions.
Alrighty, in my previous article we went through a list of product management theory and reference material which lays the foundation for the terminology, standardized procedures, and best practices.
Now we need to roll up our sleeves and get immerse on the practical side!
We are going to start with User Story Mapping. Let’s remember, story maps look at the big picture and it facilitates rich discussions about product vision, potential users, their needs, key product capabilities, minimal viable product, product releases, their goals, risks, and priorities. It is about creating a shared understanding of the following narratives:
Many people in tech use these terms interchangeably but I would definitely not use them this way. The best way to identify the differences between a Product Manager and a Product Owner is to identify their responsibilities and analyze what is their focus:
To give you a little context, I have been in software development for more than a decade and my roles have been developer, QA, and QA lead. A few months ago, as my QA manager was preparing for his retirement, he mentioned how he could see me going forward into product management. Note that I have been working under his wing for eight years and during that time we overcome many challenges so I valued his opinion. This was an idea that I kept in the back of my head, but it resurfaced when the new QA manager (another person…
Our definition of happy isn’t very good
“Why aren’t you smiling? Aren’t you happy? Is there something wrong?”
These are questions that I hear very often and make me feel terribly annoyed. We don’t really know what happiness is or how to measure it. Just a smile could easily mean 20 different emotions. Personally, being “happy” at my job involves feeling engaged, meaningful, pleasant and comfortable in my working environment. Feeling good about my daily routine. There are ways to be this kind of happy at work and it doesn’t take much from ourselves to put them in practice.
Todavía estamos lejos de alcanzar un número ‘balanceado’ de mujeres en la tecnología. Hoy en día, sólo el 25% de las ocupaciones informáticas del mundo son ocupadas por mujeres. Imaginemos el porcentaje para un país latinoamericano, donde nuestras tecnologías están emergiendo y la posibilidad de estudiar cualquier tema relacionado con la tecnología desde una edad temprana es prácticamente inexistente.
Un dato de “viejo” trasfondo: En el 2003, cuando estudié Ciencias de la Computación, sólo el 10% éramos mujeres. Más adelante en 2014, durante mi grado de Maestría éramos aproximadamente 20–25%.
ESTAMOS haciendo algo al respecto, estamos mejorando. Pero necesitamos más…
We are still very far away from equality of women in technology. Today, only 25% of the world’s computing occupations are held by women. In Latin America, technology education is emerging and the possibility of studying any technology related topic from an early age is practically non-existent.
A bit of an “old” background: 2003, when I studied computer science, only 10% were women; later in 2014, during my masters degree we were roughly 20–25%.
We ARE doing something about it. But we need more. We need to continue taking our message to every corner. Thankfully due to networking we are…
Or worst case scenario… you are forgotten. It is really difficult to keep up with growing teams. When I started in Nearsoft we were around 50 people, now we are almost 250. Currently, our newbies could say: “Ah, yeah… Artemisa, she’s the first nearsoftian to use the #StudyRemote campaign, but I have never seen her”, and they can probably identify me by one or two things that I have contributed which are visible in our offices. But that’s it.
Last month, I had the opportunity to teach the first iSQI® Certified Agile Tester️ training in México and very proudly at @Nearsoft headquarters where I currently work as a Software QA Engineer. It’s been quite a long road to reach this point, with obstacles along the way but it has been taught and trainees have taken the exam… yay (whew)!
What’s the big fuzz about this training? Well, there are many training programs out there for developers, but for testers the scene is a little limited; likewise we must choose the right option based on specific objectives. After a lot…