Archive for the Project Backlog Category

How to Prioritize Requirements YouTube Video

Posted in Agile, Business Value, Project Backlog, Release Planning with tags , , , on July 24, 2010 by vikramadhiman

I have written about how to prioritize before:

As Agile Product Managers, you are constantly prioritizing requirements to get higher value items out sooner. One approach I saw recently, seems very promising. Here is the video. Go ahead and watch it.

Basically, divide your requirements into four quadrants with Y-axis being Business Value and X-axis being Complexity. Hence, you would ideally do quadrant number 1 first and quadrant number 4 last. You can take a call between quadrant number 2 and quadrant number 3 – depending on what your current business strategy/ pull is. Simple. Do it over and over again and we will always provide higher value first.

Advertisements

Team Leads or Project Managers as Scrum Masters

Posted in Agile, Change, Project Backlog, SCRUM with tags , , , on July 22, 2010 by vikramadhiman

In organization after organization, transitioning to Scrum, you see one common pattern. The pattern has existed for at least 03 years now. The pattern is seen in all organizations [at least in India] – established big names as well as upcoming talked about/ blogged about startups. There is a team and there is a Product Owner [or Manager]. So far so good. There is also a Scrum Master – who is also the Project Manager/ Development Manager/ QA Manager/ Program Manager/ Project Lead/ Team Lead/ Developer/ Tester. This raises some questions.

Why is this happening?

I haven’t quite figured out [as yet] why if you are transitioning to Scrum, would you want this to happen – especially when Scrum Master is defined as a full time role in Scrum. The feedback I get is mostly around these lines:

  • There are not enough Scrum Masters available. We can’t just keep waiting for them to turn up. Hence, we identify people internally who can play this role. And, no one wants to do this role full time or take on this title officially. So, there we go. Do your 2 plus 2 is 4.
  • There does not seem to be any value in this role being a full-time – it is something you can do part-time. How much time can removing obstacles for the team actually take?
  • Serving the team, Protecting the team, Helping the team, Guiding the teams use of Scrum is something, which everyone should do and different people are already responsible for these things.

It is easy to dismiss or scoff at these [especially the latter], but these arguments actually seem to be true. I know for a fact that there are not enough Scrum Masters available [possible topic for another blog post]. I also know, that in an organization internally, not enough people are kicked enough to play this role. And, no matter what argument you give, the management is never convinced that this can be a full-time role especially when they see others doing this role.

Is this a good practice?

My views on “doing something just because ABC or some book or some user group discussion says so” are well known. Don’t do it. It is also said, that having no Scrum Master is better than having no Scrum Master. Before we address the question – Is it a good practice for Team Leads/ Project Managers/ Developers to be also Scrum Master, we must see what is it that a Scrum Master does. Like most things, lets start with Wikipedia, “Scrum is facilitated by a ScrumMaster, also written as Scrum Master, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal/deliverable. The Scrum Master is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of rules. A key part of the Scrum Master’s role is to protect the team and keep them focused on the tasks in hand.” Scrum Masters use soft power, servant leadership and trust to help the team become better. Scrum Masters also surrender complete control to Product Owner and the Team.   Some of the qualities we look for in a Scrum Master are humility, staying in the background, integrity and gain trust. We obviously see the clashing red flags here – the Scrum Master is not a leader. However, typically, the Leads/ Managers are that. The team is reporting to them. However, nothing that we talked about in Scrum Master’s role says that you can not have that with the team reporting to you or you working part-time as a developer/ tester. In fact, some people could argue otherwise. If you are a developer and you are convincing everyone to test, you can lead by example. So, let me stick my neck out and say – “I don’t think it is a bad idea.” It is always better to get the right person play a Scrum Master – like role half time than getting no Scrum Master or lousy full time Scrum Master. However, I won’t probably call them Scrum Master. I’ll call them Scrum Evangelist or Process Owner or Scrum Owner or something like that. Why a different name? Because, the team does not report to Scrum Master [yes, just because of that]. And, anyways, it wont be the name, but the intent and the action of the person that will play out louder in the transition scheme of things. Also, you should get these people [and the rest of the team and Product Owners] good coaching.

Some of these people [Process Owner or Scrum Owner] will make Scrum a bad word in the organization. But, so could many Scrum Masters and Product Owners [and even the teams for that matter]. The hope is that organization will pick the right people for this role. Like the rest of the organization, these people [whatever you have called them] will also transition.

Scaling Product Owner Role in Scrum : Potential Issues and Workarounds

Posted in Agile, Collaboration, Project Backlog, SCRUM with tags , , , , , on February 23, 2009 by vikramadhiman

In the previous post on “Multiple Product Owners or Not“, I analyzed if there is a case for multiple product owners. As per me, there can be grounds and case where this is a necessity. Now let’s see if we did indeed have 02 product owners, what will happen. The potential problems [I have seen these] could be:

  • Product owners have power – they influence the product direction. As long as 02 or more product owners agree on the direction, it is fine. However, product owners also influence product execution [user interface, test cases, priority]. These are soft areas and different people can interpret these differently.
  • Each product owner is likely to have more appreciation for their own features and their importance, than of the other product owner. If both of them feed a common development team, there would be issues of working together at some stage or the other.
  • If you have product owner depending on expertise [horizontal slices than vertical slices], there will be even more potential for disaster striking soon. Let’s take an example. Something which is good from SEO perspective, might not be so great from user interface perspective. If we have 02 product owners, one for SEO and one for user interface, major conflicts will arise.
  • Having a whole lot of people influence product direction can mean paralysis in decision making, where almost the bare minimum everyone can agree on, only gets done and anything exciting and challenging, will never even be attempted.

There are some things one can try, to make multiple product owners work together. Let’s look at some possible solutions:

  • One way to work around this is to have all the members of the team as stakeholders, but have a Chief Product Owner to have the final responsibility of prioritization. Hence, depending on the size and nature of your product, one might have group of people responsible for grooming the product backlog [design, SEO, user acquisition, interface, development, marketing] but only one person should be responsible for overall prioritization as well as decision making in case of conflict. The problem in this case is to identify such a person. Typically, such a person would be someone with great knowledge about the product, marketing and strategic objectives. This is the typical approach and this takes along specialists in various domains together. Although, this is against the idea of generalists not specialists, it is needed. I personally believe specialists have their place and very important one too. I have benefited as a Product Manager from people advising me on aspects I will overlook or most likely not even know. Specialists give me insight from marketing perspective – Internet Marketing (paid), Internet Marketing (organic), Offline Marketing Channels, User Behavior … one which [A] I won’t ever get time to analyze in detail or [B] would need enormous training to even get started.
  • Another approach is to divide the product in multiple sub-products. The Chief Product Owner can divide work to other Product Owners depending on their expertise, experience and importance of the features. This is commonly called feature teams. Organizations and products which spend time on this, reap benefits. We are getting started on this and this is streamlining our processes. There will always be areas where the Chief Product Owner would step in, but mostly delegation and scalability of product owner roles is supported through this model.

One Product Owner Only or More Than One?

Posted in Agile, Collaboration, Project Backlog with tags , , , , on February 21, 2009 by vikramadhiman

Once every few months, debate on “Whether there is a case for multiple product owners” comes back in Scrum and Agile Community. Most often, the response by Scrum Community is – No. There should be only one product owner and there CAN NOT BE more than one product owner. There are some [like me], who suggest that after the very first releases out, the product becomes too big and complex and multiple directions emerge and one person does not have full knowledge or expertise or even time to be able to do the job of a product owner effectively.

Let’s start by looking at the role of a product owner. Product owner is the main decision maker on behalf of the stakeholders, users, customers and clients. Product owner decides what is to be built and when. Product owner is not the only contact but most likely the primary contact for the team. If the team has only 01 product owner, it should theoretically move faster. One person would make faster decisions and team will get used to working with one person after a few sprints, fostering increased collaboration and more agility. This works fine if the product owner is available and qualified to make these decisions. However, this might not always be the case. As the product grows, there would be multiple directions, sub-products and large development teams. One product owner might just not be qualified or even available to take the product further. Hence, if 01 product owner is the bottleneck [does not have time, does not have competence], adding a product owner might be a good or only option. This is not always smooth and not without its problems. However, this is the only option available. And like scaling development teams and Scrum Master role, Product Owner Role also needs to be scaled.

The main argument against why there should not be multiple product owners, is that in Scrum, Product Owner is the single wringable neck. So, once you have more product owners, you won’t know whose neck(s) to wring? This according to me is a no starter argument in the first place. I have never understood the concept of single wringable neck at all. How can one person be so powerful as to be responsible for the overall success of the product? Product Owner trusts various people to give the right input. Product Owners listen to various people who give their own input and then prioritize features. Success or failure of these features [some of which can take time to reflect], are dependent on the advice. It is a collaborative, snyergestic relationship between domain heads and product owner. Both are in it together, and not separate. Further, the idea of single wringable neck goes against the ideals of Agile as well. What is the use of wringing someone’s neck after product fails? Why not start with “Everyone did everything in their power to make the product successful” thinking to the product owner as well? And, most importantly, can “we need 01 single wringable neck” potentially overpower a solution that can work [and works] of scaling the product owner role further?

In my next post : Scaling Product Owner Role in Scrum : Potential Issues and Workarounds

Project A: Drafting a Product Backlog – Part A

Posted in Coaching at Net Solutions, Project Backlog with tags , on November 26, 2006 by vikramadhiman

With Project A we had a Project Backlog at the start. Somehow we forgot how to update it. However, it seems that it is never too late to revisit one and keep the project on track. One of the main reasons, why we are not able to track project and sprint backlogs is because no one understands why should we do so. Our organization is transitioning from a “no-process” development style to SCRUM project management. Hence, writing a backlog and tracking tasks in the sprint backlog is somewhat of an overhead and unchartered territory for most teams. Without a prioritized queue of work yet to be done in the project, we are all going in all the directions possible without knowing what to do and where we are going in the project. We need to start working based on a prioritized list of things rather than ad-hoc requests at the earliest.

It is widely recognized and accepted that project backlog and sprint backlogs are artifacts which the team owns. I also understand that eventually the team has to do this. After all, we will be a successful SCRUM team only when these artifacts are owned/ drafted by the team.

However, I am having a hard time overcoming the instincts to draft one myself and present it to the team. I feel and understand that the team needs to be mentored over a period of time on how to draft the project and sprint backlog. Maybe I can invite them on the discussion on whether the stories for the project and sprint backlog are complete and what does “done” for these items means. Also, get them to understand the motivation for priorities and delivering “value” first. As much as I hate it, I think I will need to draft the project backlog for now. However, lets give it a try and see if the team can draft the sprint backlog for the coming sprint or not.