Saturday February 2019 MachinesTalk participation in the 2nd Saudi IoT
Company employees sharing thoughts and ideas
Each year there is a day that sets the organization’s atmosphere heavy. All employees are notified the day before to tidy up their place before leaving and look sharp tomorrow, as all the executives are gathering for a meeting at the headquarters. This meeting goes on for hours, sometimes a whole day. It is a strategic meeting for the current year. According to the organization’s strategic goal, they discuss the options which would help them achieve that goal and earn from it. At the end of the meeting, they decided on the solution “A’s” vision which aligns with the organization’s goal. This vision is assigned to the Product Owners (POs) and they are asked by executives to do research about it, develop its products’ roadmap, and start the work on it. The POs then do research about the product and start to develop user stories accordingly. Once they have enough stories, release planning is scheduled with the team, which actually happens as a sprint planning., At the end of the planning meeting, PO asks the team “So let’s start the sprint
1?”. However, a better question would be: Is this the right way to start?
I am not saying this is how things happen in every organization. It surely happens this way in some.
From the above scenario, it seems that PO doesn’t know an efficient way of starting the work properly in an Agile environment (i.e.: where an organization is using Agile methodology/framework to manage their work).
But then who does?
People have been working in traditional project management ways for so long that it has become difficult for them to shift towards agile ways of working. Mean while, all of us are still learning agile as well.
Besides, while in an agile there are many ways to do the same thing, there are ways that are more efficient. A lot of training and materials are available which talk about the why and what, but very few talks about “how to do”.
In this article, I am attempting to point one of the “How to do’s” of efficient ways of working for POs in an agile environment, (after all its one of Scrum Master/Agile Coach services to PO & team to work in an efficient way). Let’s explore them now.
When a PO is assigned a product’s vision, they rarely receive any concrete requirements about it. So how could a PO drive a product backlog from its vision?
POs usually have to work closely with stakeholders to understand their requirements, their needs of the new product/system (there is a reason why the PO is called the voice of stakeholders) and express them in the form of user stories.
Although user stories are not the only way to express requirements, they are not the focal point of this article. For simplicity’s sake, let us just stick with them. While working with stakeholders, PO’s get loads of ideas which they simply add in the backlog.
Now comes the tricky part. Let’s take an example. Assuming that the development team can complete on average four to five stories in a sprint and that during the sprint, five to six more ideas would emerge on average. What do you think will happen?
In the pursuit of making all stakeholders happy by saying “Yes” to every new idea and adding them in the backlog, it will become impossible for the PO to manage. If PO simply adds the ideas in the backlog, it will become way too exhaustive. Thus, transparency would become impossible and no one will know where the product is headed — with respect to the organization’s goal. In other words, POs should not treat product backlog as an ideas or requirements repository. Because ideas are easier to come up with rather than a quality working product/system.
It is the PO’s job to decide what to include in the Backlog and what not. As per the Scrum Guide,
“The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.”
Maximize the outcome by maximizing the development team’s output is a good idea. But how would you do that?
Well, by managing the product backlog and saying “No” to some ideas/features. I know, it’s easier said than done. So instead of firing a blunt “No”, there is another trick in the bag for PO’s to use: “Prioritization”. If saying “No” is hard to do then at least PO should be able to explain & convince stakeholders about what is valuable to develop right now
and what is not.
OK, I am deviating from the topic, so let’s bring our focus back on the “How to do” part again.
Developing the product backlog from vision is certainly not a one person’s job. POs alone can’t validate the feasibility of the ideas/features and they can’t develop a use experience/design on their own.
Therefore, we need to bring the right people to the room: technical experts (if development team is not assigned or not available, otherwise team should do it) to validate the feasibility of the solution and user experience/design experts. From here we need to decompose the vision to our initial product backlog by using one of the user
centric approach called “User Story Mapping”.
User story mapping is a visualization of the journey a user takes using a product. It also helps in identifying who the end-users are and focus on implementing user stories which provide the most value to them. Let’s start with the following steps:
• Develop user’s personas to understand the problems end-users need to address and how our system will help them solve these problems.
• After personas, identify high level stages that the users will take as they journey through the product. This step is called “Developing a Backbone”.
• Once stages are identified, we need to add details of high-level stages by listing the activities the users would perform for each stage. This step is called “Building the Body/Walking Skeleton”. Activities are often represented as Epics (features or business requirements).
• Then we will dive one more level down by dividing each epic (e.g. feature) and adding more details to them. We have reached the famous user stories.
When could we say it is enough?
There is really no end to this exercise. We can keep working together to come up with more ideas using generative ideas techniques (brainstorming, social listening, etc.). However, the main goal here is to identify all user stories according to our current level of knowledge and understanding about the product. Later on, according to reviews/feedbacks, we will be able to add more items in the backlog.
• Last step is about “Identifying MVP and Prioritization”. There are many prioritization techniques: MoSCoW, Weighted Shortest Job First (WSJF), Kano Model, etc. These techniques should help us identify which items would provide the most value to the end- user, keeping the user’s journey in mind. These items would constitute the features of the Minimum Viable Product (MVP).
After identifying the MVP, the next step would be to do the release planning, in which the team would estimate stories and divide items in sprints by assuming capacity and initial velocity. This is another big topic to discuss.
This is just the start of devising the product backlog from its vision. However, the work is not finished here. It would require more than one article to cover this topic. Till then, let me know your thoughts in the comments about this article and stay tuned for more. Keep Agiling On!
