Search

Scrum Master Filter

How to Transition From Project Manager to a Scrum Master

Scrum Masters and Project Managers are not the same roles. I am going to talk about moving from a Project Manager role to a Scrum Master. Why do we need to talk about it? Because many people think they are the same thing with different artifacts or different language being used. They aren’t.You may be considering a change of roles from Project Manager to Scrum Master. You may be forced into such change as your organization is subjected to an Agile transformation. You may find yourself juggling both the roles and struggling with the competing agendas embedded in the two roles.  What I want you to get from this essay is an appreciation of the differences between the Project Manager and Scrum Master and some ideas about how the role of the Project Manager fits into Agile.The benefits of being a great Scrum MasterThe first and obvious answer is the huge drive to have an Agile delivery capability in almost every organization in the world. It’s a hot new job and having these skills and experiences to improve your employment prospects as you look for work.While there are still more Project Manager jobs than Scrum Master jobs on the jobs boards, the number of Scrum Master and similar jobs continues to grow, while the number of Project Manager jobs appears to be steady, and perhaps even shrinking in some markets.Additionally, more and more Project Manager roles require an understanding of and experience in Agile development and management methods, as project performance seems strongly correlated with the use of Agile methods.So, getting good in-depth experience in Agile working is an important step in your professional development, especially if you are a Project Manager involved in technology projects. Doing a job as a Scrum Master is an excellent way to immerse yourself in Agile world and learn the skills, knowledge, and behavior that will help you be a great manager and leader later in your career.But wait! There’s more.Many, many, many people who adopt the role of Scrum Master find their way into a new and fulfilling career. Scrum Masters and related coach type roles are inherently fulfilling for many people. Scrum Masters report a huge sense of satisfaction in being valuable team members and helping those around them grow in capability and deliver successful outcomes.  Becoming a Scrum Master may be the beginning of a whole new career track for you.Why to switch from Project Manager to a Scrum Master roleLet us have a look at the three key areas from where you can make out the decision on why the Scrum Master can be a great alternative for a typical project management environment:The potential to focus on the current taskDuring a project, the Project Manager has to discuss with the Client team and the Developer team to ensure the project goals. Being a Project Manager, it is very time-consuming and burdening as they have to ensure that the team is adhering to their own high standards.Whereas, Scrum Masters set priorities and target depending on sprint cycle. Scrum Master always keeps an eye on the active sprint. Scrum framework reduces distractions and the stress of achieving several different goals simultaneously. Being a Scrum Master, it is very easy to manage the projects as the Scrum framework allows to-Narrow the focusMeasure the results at each SprintGive the fastest deliveryDifferent ways to manage projectsMostly Project Managers spend much of their lives in:Collecting resourcesVerifying the resourcesEnsuring that everybody has what they wantFacilitating communicationScrum methodology allows to solve queries by communicating with the team members. The team can resolve issues without the help of the Scrum Master and the issues which can’t be solved by the team can be raised during ‘Daily Scrum’. Scrum meetings last for 15 minutes. In those 15 minutes, the Scrum Master will come to know the project status and the roadblocks hindering the project success.The Scrum method allows the teams to carry out communication by:Allowing the teams to communicate to solve issues internallyThe Scrum Master can get project status update in 15 minutes of Scrum meetingThe Scrum Master gets the things that can keep the project runningPrepare for what the client likesClients keep project goals like high ROI (return on investment), quality, reliability and higher lead conversion rates, before approaching any company. Along with the goals, clients want to know about the process and a collaborative relationship.Project manager manages the timeline, limitations, and achievements. They decide on the future aspects of the processes. This method is difficult to manage and works smoothly through changing priorities and resources.  On the flip side, in Scrum method goals, priorities, and resources can be set during Sprint planning. Since Sprint lasts for 2-3 weeks, they set target within a timeframe which allows them to accomplish the target in time and with less errors. The Scrum Master, developers, and teams, all are allowed in the Scrum planning process, so everyone can discuss the process for achieving the client’s requirement. This method allows the client to get the regular status of the project and allows us to create an awesome productTips for transitioning from Project Manager to a good Scrum MasterIf you are a Project Manager entering the Agile world, you probably have the reasons to switch from the Project Manager role to the Scrum Master. You already have a definition of a Project Manager’s role in your head.  It is probably based on the PMI definitions around planning, monitoring, controlling and closing a project. Maybe there is something about the accountability for the outcomes, and using the project management industry’s established methods and practices. That’s all good and a great set of knowledge to have.The best resources to learn what is a Scrum Master, what a Scrum Master does are from reading the Scrum guide and from talking to people who have experience in the role, most of whom are very generous with their time and enthusiastic about sharing knowledge and experiences.  The actual description of the Scrum Master role is very simple, clear and succinct.  The stories you get from the experienced people will help you see the complexity of those clear guidelines applied in complex situations.The most important contributions of the Scrum Master role are enabling the team by helping them unlock value from executing the Scrum framework well, being collectively disciplined and organized as a team, and in spending time and energy clearing impediments to the team’s progress.A Project Manager playing a Scrum Master role for the first time, would not be the first person to make the mistake of thinking the role is all about the process control. But it isn’t. It is an enabler role.As a Project Manager, you might hold accountability for creating a plan and for publishing progress reports against that plan to the Stakeholders.  As a Scrum Master, you are accountable for enabling the team to produce a plan and publish progress reports.You may end up being the person who grabs progress data and publishes it, but you are doing it in service to the team rather than to service your own delivery accountabilities. You may have very little to do with publishing progress reports. Anybody on the team or the team collectively can perform that task.Your job is to help the team understand the need for progress reports, to help them find useful methods to get the job done, and to find the discipline to consistently do the job well.The Scrum Master is advised to use the Scrum framework as a tool to inspect and adapt to both the product demands and the capabilities of the team. As your team learns new things, they will prioritize the opportunities and make changes according to the way they operate.  You can help them identify the opportunities and implement them. There are several easy ways to access methods and tools to solve a variety of problems out there, both inside and beyond the Agile toolkits, but the team should not settle for any obvious best practice. Good practices should be used, not to be settled. Always seek better.We have already looked at how your accountabilities change, but a Scrum Master won’t succeed unless they approach the work with the right attitude.  Each team is different, so you should always assess the expectations of the team and the role you play. Also, you will be able to bridge any gaps by using some fair core values based behaviors that people expect from a Scrum Master.Servant leadership — the watchwordThe Scrum Master role is a Servant Leader role. The Servant leaders seemingly face a conundrum that ‘how do I serve and lead at the same time’.  The answer is that you lead some things with authority based on the expertise and knowledge. You also step aside and let others manage their things based on authority, experience, and roles.For example the Product Owner in Scrum has positional authority on the backlog (that is supposed to be based on knowledge, but is also deeply positional.)You are expected to bring an authority, based on knowledge and experience around the  Scrum, team and system dynamics, and it should be valued by the team. To do this effectively you need to follow some tips for transitioning to the Agile Project Manager.Know your stuffKnowing only what to do leads to cargo cult practices and doesn’t engender a learning organization that continually evolves.  How and why Scrum worksWhy does each of the attributes of Scrum bring value?What problems do they solve and why does that part of Scrum work the way it does?You also need to know why Scrum parts work more effectively when it is executed integratively.New Scrum teams: Start with a Big Bang?If you are working with a team which is new to Scrum or Agile practices, as an effective Scrum Master you should also have some expertise in the way you roll in or implement the new Agile ways of working. Should you do a big bang implementation of Scrum, or roll in one practice at a time? Which one should you start with? Which next?The answer will depend on the circumstances of the team and the Scrum Master should have enough experience and wisdom to have an opinion that the team value because ideally, the teams should be deciding how to roll in the practices.Ask outcome-focused questionsAn important operating method for Scrum Masters is to highlight issues and ask questions.  When and if people express interest in the topic being raised, the Scrum Master may then offer advice and suggestion options. Collectively, the team should engage in the issue and decide what to do.  If the Scrum Master feel that the teams are going to make a mistake, you think about whether the mistake will be small enough to be safe and whether the team will take lessons from the failure. If you see risks, raise them and try to influence the down team with the different paths.As you interact with the team, your experience and advice should become more valued by the team over time.  You should build a consistent track record of helping them become a more successful team. You should not have to try to force change, although sometimes you will feel like you do, and some even rarer times you may feel you have to invoke authority from the management to force something.The importance of feedbackScrum and Agile methodology rely very heavily on fast and transparent feedback. As a Scrum Master, you have an initial feedback system laid out from you in the form of the Scrum ceremonies. These are just the beginning though. You and the team should continuously look to tune and improve your feedback systems so that the team can continually find better ways of delivering better business outcomes.Part of the Scrum Master’s role might be to look at the feedback system, to help the team assess whether they are the right ones and to find better ones.  Sometimes, a Scrum Master finds new ideas about feedback that a team might miss. The team members are all heads down building products and solutions and often prioritize ‘the work’ over ‘the system’.But a Scrum Master can bring an outsider’s perspective, or might be more able to observe the wider system the team operates in. Don’t be afraid of expressing your observations and ideas to the team where you have an insight that they don’t have. That perspective can be very valuable.  You will often be the first to see when a change needs to be made and can let the team know it’s time to start thinking differently.Getting feedback on your own performanceHave a plan for how you are going to grow and become great at the role.  Pursue continuous incremental improvement by setting up regular short cycle feedback systems on yourself.  Pause and reflect on how you are going and what you should do to improve. Do it regularly, and no less frequently than the sprint cycle.  Keep checking with the team whether they need help and what they would like you to help them with, and when you are done, check what they thought of your efforts.Get experience, get training, get a coach or mentor and find a community of practitioners that you can connect with and learn from. Leverage the experience from others, as the people who do this work love to help others and make themselves generously available.Traps in transitioning from Project Manager to a Scrum MasterHere are some of the traps in transition that can be avoided by a Project Manager who has recently assumed the role of a Scrum Master.Responsibility to organize meetingsAgile Manifesto principles believe in building projects collaboratively. Scrum Master arranges meetings for the teams whenever necessary. This is unlike a traditional Project Manager who used to be an administrative assistant to schedule meetings for everyone. Scrum and Agile give an importance to the individuals and interactions over processes and tools.Mistaking the ‘Daily Scrum’ as a ‘Status Update’ taskScrum Master arranges the ‘Stand-ups’ to communicate with the team members. The traditional Project Manager keeps track of everyone’s work to update the project plans and finding out the finishing dates. In Scrum, teams act as self-directing and accountable. So, after their transition to the Scrum Master’s role, the earlier Project Managers should be mindful about their perception of “daily scrum”. The point should be sledgehammered to the minds of these new Scrum Masters that daily scrum is only for the purpose of discussion and is not a status update task.Being a ‘Scrum Master’ is the only jobScrum Master’s role should be multifaceted as an SM has to play the ideal servant-leader role. Also, his role keeps changing in some Agile teams. If any task is incomplete and the Scrum Master is capable of doing it, they should pick up and implement the task. Scrum guide states that “helping the development team to create high-value products”, is one of the services of the Scrum Master. Therefore while transitioning from Project Manager to the Scrum Master, it is important to keep in mind that Scrum Master is not a unidimensional role. It entails multiple aspects.Improper Stakeholder Communication ManagementIn Scrum, the progress is measured as a ‘working software per Agile Manifesto’. The issues are raised, analysed and solved by the team with an external help if necessary. The Scrum Master may not be able to manage the objective the team uses to collaborate. The required deliverables may be set already if there is a governing body such as a portfolio management group or a project management office. In such cases, Scrum Masters should spot the reality that issues are flexible and alter depending on the work committed by the team. Detailing out risks can be ignored, as they will be outdated within a few days or even minutes.ConclusionTransitioning from Project Manager to Scrum Master can be a challenging yet fun. You just need to be very careful. It is important to help with reflection and coaching so that the new Scrum Masters leave some habits behind. When it comes to transitioning to the Scrum Master role, you definitely cannot achieve everything overnight. The first vital step is to get laser-focused. Certifications, as we discussed earlier can be the best if not the only way to do it. All the best for your transition.

How to Transition From Project Manager to a Scrum Master

1862
  • by Craig Brown
  • 09th Oct, 2018
  • Last updated on 05th May, 2021
  • 4 mins read
How to Transition From Project Manager to a Scrum Master

Scrum Masters and Project Managers are not the same roles. I am going to talk about moving from a Project Manager role to a Scrum Master. Why do we need to talk about it? Because many people think they are the same thing with different artifacts or different language being used. They aren’t.

You may be considering a change of roles from Project Manager to Scrum Master. You may be forced into such change as your organization is subjected to an Agile transformation. You may find yourself juggling both the roles and struggling with the competing agendas embedded in the two roles.  

What I want you to get from this essay is an appreciation of the differences between the Project Manager and Scrum Master and some ideas about how the role of the Project Manager fits into Agile.

The benefits of being a great Scrum Master

The first and obvious answer is the huge drive to have an Agile delivery capability in almost every organization in the world. It’s a hot new job and having these skills and experiences to improve your employment prospects as you look for work.

While there are still more Project Manager jobs than Scrum Master jobs on the jobs boards, the number of Scrum Master and similar jobs continues to grow, while the number of Project Manager jobs appears to be steady, and perhaps even shrinking in some markets.

Additionally, more and more Project Manager roles require an understanding of and experience in Agile development and management methods, as project performance seems strongly correlated with the use of Agile methods.

So, getting good in-depth experience in Agile working is an important step in your professional development, especially if you are a Project Manager involved in technology projects. Doing a job as a Scrum Master is an excellent way to immerse yourself in Agile world and learn the skills, knowledge, and behavior that will help you be a great manager and leader later in your career.

But wait! There’s more.

Many, many, many people who adopt the role of Scrum Master find their way into a new and fulfilling career. Scrum Masters and related coach type roles are inherently fulfilling for many people. Scrum Masters report a huge sense of satisfaction in being valuable team members and helping those around them grow in capability and deliver successful outcomes.  Becoming a Scrum Master may be the beginning of a whole new career track for you.

Why to switch from Project Manager to a Scrum Master role

Transition Project Manager to a Scrum Master


Let us have a look at the three key areas from where you can make out the decision on why the Scrum Master can be a great alternative for a typical project management environment:

The potential to focus on the current task

During a project, the Project Manager has to discuss with the Client team and the Developer team to ensure the project goals. Being a Project Manager, it is very time-consuming and burdening as they have to ensure that the team is adhering to their own high standards.

Whereas, Scrum Masters set priorities and target depending on sprint cycle. Scrum Master always keeps an eye on the active sprint. Scrum framework reduces distractions and the stress of achieving several different goals simultaneously. Being a Scrum Master, it is very easy to manage the projects as the Scrum framework allows to-

  • Narrow the focus
  • Measure the results at each Sprint
  • Give the fastest delivery

Different ways to manage projects

Mostly Project Managers spend much of their lives in:

  • Collecting resources
  • Verifying the resources
  • Ensuring that everybody has what they want
  • Facilitating communication

Scrum methodology allows to solve queries by communicating with the team members. The team can resolve issues without the help of the Scrum Master and the issues which can’t be solved by the team can be raised during ‘Daily Scrum’. Scrum meetings last for 15 minutes. In those 15 minutes, the Scrum Master will come to know the project status and the roadblocks hindering the project success.

The Scrum method allows the teams to carry out communication by:

  • Allowing the teams to communicate to solve issues internally
  • The Scrum Master can get project status update in 15 minutes of Scrum meeting
  • The Scrum Master gets the things that can keep the project running

Prepare for what the client likes

Clients keep project goals like high ROI (return on investment), quality, reliability and higher lead conversion rates, before approaching any company. Along with the goals, clients want to know about the process and a collaborative relationship.

Project manager manages the timeline, limitations, and achievements. They decide on the future aspects of the processes. This method is difficult to manage and works smoothly through changing priorities and resources.  

On the flip side, in Scrum method goals, priorities, and resources can be set during Sprint planning. Since Sprint lasts for 2-3 weeks, they set target within a timeframe which allows them to accomplish the target in time and with less errors. The Scrum Master, developers, and teams, all are allowed in the Scrum planning process, so everyone can discuss the process for achieving the client’s requirement. This method allows the client to get the regular status of the project and allows us to create an awesome product

method to get awesome product


Tips for transitioning from Project Manager to a good Scrum Master

If you are a Project Manager entering the Agile world, you probably have the reasons to switch from the Project Manager role to the Scrum Master. You already have a definition of a Project Manager’s role in your head.  It is probably based on the PMI definitions around planning, monitoring, controlling and closing a project. Maybe there is something about the accountability for the outcomes, and using the project management industry’s established methods and practices. That’s all good and a great set of knowledge to have.

The best resources to learn what is a Scrum Master, what a Scrum Master does are from reading the Scrum guide and from talking to people who have experience in the role, most of whom are very generous with their time and enthusiastic about sharing knowledge and experiences.  

The actual description of the Scrum Master role is very simple, clear and succinct.  The stories you get from the experienced people will help you see the complexity of those clear guidelines applied in complex situations.

The most important contributions of the Scrum Master role are enabling the team by helping them unlock value from executing the Scrum framework well, being collectively disciplined and organized as a team, and in spending time and energy clearing impediments to the team’s progress.

A Project Manager playing a Scrum Master role for the first time, would not be the first person to make the mistake of thinking the role is all about the process control. But it isn’t. It is an enabler role.

As a Project Manager, you might hold accountability for creating a plan and for publishing progress reports against that plan to the Stakeholders.  As a Scrum Master, you are accountable for enabling the team to produce a plan and publish progress reports.

You may end up being the person who grabs progress data and publishes it, but you are doing it in service to the team rather than to service your own delivery accountabilities. You may have very little to do with publishing progress reports. Anybody on the team or the team collectively can perform that task.

Your job is to help the team understand the need for progress reports, to help them find useful methods to get the job done, and to find the discipline to consistently do the job well.

The Scrum Master is advised to use the Scrum framework as a tool to inspect and adapt to both the product demands and the capabilities of the team. As your team learns new things, they will prioritize the opportunities and make changes according to the way they operate.  

You can help them identify the opportunities and implement them. There are several easy ways to access methods and tools to solve a variety of problems out there, both inside and beyond the Agile toolkits, but the team should not settle for any obvious best practice. Good practices should be used, not to be settled. Always seek better.

We have already looked at how your accountabilities change, but a Scrum Master won’t succeed unless they approach the work with the right attitude.  Each team is different, so you should always assess the expectations of the team and the role you play. Also, you will be able to bridge any gaps by using some fair core values based behaviors that people expect from a Scrum Master.

Servant leadership — the watchword

The Scrum Master role is a Servant Leader role. The Servant leaders seemingly face a conundrum that ‘how do I serve and lead at the same time’.  The answer is that you lead some things with authority based on the expertise and knowledge. You also step aside and let others manage their things based on authority, experience, and roles.

For example the Product Owner in Scrum has positional authority on the backlog (that is supposed to be based on knowledge, but is also deeply positional.)

Servant leadership


You are expected to bring an authority, based on knowledge and experience around the  Scrum, team and system dynamics, and it should be valued by the team. To do this effectively you need to follow some tips for transitioning to the Agile Project Manager.

Know your stuff

Knowing only what to do leads to cargo cult practices and doesn’t engender a learning organization that continually evolves.  

  • How and why Scrum works
  • Why does each of the attributes of Scrum bring value?
  • What problems do they solve and why does that part of Scrum work the way it does?
  • You also need to know why Scrum parts work more effectively when it is executed integratively.

New Scrum teams: Start with a Big Bang?

If you are working with a team which is new to Scrum or Agile practices, as an effective Scrum Master you should also have some expertise in the way you roll in or implement the new Agile ways of working. Should you do a big bang implementation of Scrum, or roll in one practice at a time? Which one should you start with? Which next?

The answer will depend on the circumstances of the team and the Scrum Master should have enough experience and wisdom to have an opinion that the team value because ideally, the teams should be deciding how to roll in the practices.

Ask outcome-focused questions

An important operating method for Scrum Masters is to highlight issues and ask questions.  When and if people express interest in the topic being raised, the Scrum Master may then offer advice and suggestion options. Collectively, the team should engage in the issue and decide what to do.  

If the Scrum Master feel that the teams are going to make a mistake, you think about whether the mistake will be small enough to be safe and whether the team will take lessons from the failure. If you see risks, raise them and try to influence the down team with the different paths.

As you interact with the team, your experience and advice should become more valued by the team over time.  You should build a consistent track record of helping them become a more successful team. You should not have to try to force change, although sometimes you will feel like you do, and some even rarer times you may feel you have to invoke authority from the management to force something.

The importance of feedback

Scrum and Agile methodology rely very heavily on fast and transparent feedback. As a Scrum Master, you have an initial feedback system laid out from you in the form of the Scrum ceremonies. These are just the beginning though. You and the team should continuously look to tune and improve your feedback systems so that the team can continually find better ways of delivering better business outcomes.

Part of the Scrum Master’s role might be to look at the feedback system, to help the team assess whether they are the right ones and to find better ones.  Sometimes, a Scrum Master finds new ideas about feedback that a team might miss. The team members are all heads down building products and solutions and often prioritize ‘the work’ over ‘the system’.

But a Scrum Master can bring an outsider’s perspective, or might be more able to observe the wider system the team operates in. Don’t be afraid of expressing your observations and ideas to the team where you have an insight that they don’t have. That perspective can be very valuable.  You will often be the first to see when a change needs to be made and can let the team know it’s time to start thinking differently.

Getting feedback on your own performance

Have a plan for how you are going to grow and become great at the role.  Pursue continuous incremental improvement by setting up regular short cycle feedback systems on yourself.  Pause and reflect on how you are going and what you should do to improve. Do it regularly, and no less frequently than the sprint cycle.  

Keep checking with the team whether they need help and what they would like you to help them with, and when you are done, check what they thought of your efforts.

Get experience, get training, get a coach or mentor and find a community of practitioners that you can connect with and learn from. Leverage the experience from others, as the people who do this work love to help others and make themselves generously available.

Traps in transitioning from Project Manager to a Scrum Master

Here are some of the traps in transition that can be avoided by a Project Manager who has recently assumed the role of a Scrum Master.

Responsibility to organize meetings

Agile Manifesto principles believe in building projects collaboratively. Scrum Master arranges meetings for the teams whenever necessary. This is unlike a traditional Project Manager who used to be an administrative assistant to schedule meetings for everyone. Scrum and Agile give an importance to the individuals and interactions over processes and tools.

Mistaking the ‘Daily Scrum’ as a ‘Status Update’ task

Scrum Master arranges the ‘Stand-ups’ to communicate with the team members. The traditional Project Manager keeps track of everyone’s work to update the project plans and finding out the finishing dates. In Scrum, teams act as self-directing and accountable. So, after their transition to the Scrum Master’s role, the earlier Project Managers should be mindful about their perception of “daily scrum”. The point should be sledgehammered to the minds of these new Scrum Masters that daily scrum is only for the purpose of discussion and is not a status update task.

Being a ‘Scrum Master’ is the only job

Scrum Master’s role should be multifaceted as an SM has to play the ideal servant-leader role. Also, his role keeps changing in some Agile teams. If any task is incomplete and the Scrum Master is capable of doing it, they should pick up and implement the task. Scrum guide states that “helping the development team to create high-value products”, is one of the services of the Scrum Master. Therefore while transitioning from Project Manager to the Scrum Master, it is important to keep in mind that Scrum Master is not a unidimensional role. It entails multiple aspects.

Improper Stakeholder Communication Management

In Scrum, the progress is measured as a ‘working software per Agile Manifesto’. The issues are raised, analysed and solved by the team with an external help if necessary. The Scrum Master may not be able to manage the objective the team uses to collaborate. The required deliverables may be set already if there is a governing body such as a portfolio management group or a project management office. In such cases, Scrum Masters should spot the reality that issues are flexible and alter depending on the work committed by the team. Detailing out risks can be ignored, as they will be outdated within a few days or even minutes.

Conclusion

Transitioning from Project Manager to Scrum Master can be a challenging yet fun. You just need to be very careful. It is important to help with reflection and coaching so that the new Scrum Masters leave some habits behind. When it comes to transitioning to the Scrum Master role, you definitely cannot achieve everything overnight. The first vital step is to get laser-focused. Certifications, as we discussed earlier can be the best if not the only way to do it. All the best for your transition.

Craig

Craig Brown

Blog Author

Craig’s roles over the past 20 years have involved leading project management teams, projects and programmes, consulting, training and coaching in a variety of aspects of project delivery. Most recently Craig was a program manager on Telstra’s Customer Advocacy journey, working with culture change, Net Promoter Scores, and lean-style customer centred process improvements.

Apart from the disciplines of project and portfolio management Craig is also an Agile and Lean enthusiast with a focus on the collaboration and cultivation aspects of agile practices and methods. Craig runs the Melbourne Scrum User group and also runs meetup groups for Agile business analysis and agile project managers where he helps people navigate their way from traditional roles and thinking to modern ones.

Craig also co-created the LAST conference which is a low cost community driven conference focusing on lean, agile and systems thinking.

Join the Discussion

Your email address will not be published. Required fields are marked *

9 comments

Sanvi Raj 01 Nov 2018

Awesome Blog.... informative and knowledge gaining ..Thanks

Mellissa 03 May 2019

Thank you for writing this awesome article. I'm a long time reader but I've never been compelled to leave a comment. I subscribed to your blog and shared this on my Twitter. Thanks again for a great post!

Staci 07 May 2019

Great article! Thank you :)

Nilda 10 May 2019

I like it when individuals come together and share thoughts. Great blog, continue the good work!

Luther 11 May 2019

Thanks for posting this awesome article. I'm a long time reader but I've never been compelled to leave a comment. I subscribed to your blog and shared this on my Twitter. Thanks again for a great post!

R. Beaudet 17 May 2019

Thank you for the good writeup.

Publissoft 24 May 2019

Thanks for posting this awesome article. I'm a long time reader but I've never been compelled to leave a comment. I subscribed to your blog and shared this on my Twitter. Thanks again for a great article!

Alyssia Alexandria 11 Jun 2019

Fantastic thank you for sharing this truly eye opening.

Prem kumar 24 Jun 2019

This information is more valuable & use full thanks for providing such kind of blog...

Suggested Blogs

The Ultimate Guide to Product Roadmaps

Before starting any project, be it Agile, waterfall or even non-IT projects, it is important for the people involved in the product to understand what it is they are building. In other words, it is important to understand the vision and mission of the project and the product being built and how it aligns with the values of the organization.This feature that outlines the strategic path to be followed for developing a particular product is called the product roadmap. The product roadmap is more of a communication tool and helps to communicate the high-level purpose of the product’s strategy and its alignment with organizational business objectives.What is a Product Roadmap?A product roadmap is a plan of action for how a product or solution will evolve over time--Atlassian In other words, a product roadmap is a plan of action that defines the short- and long-term goals of the product to be built. The product roadmap is used not just in waterfall projects but is crucial for Agile projects too and is often used by the Product Owner to outline how the product will shape up, its functionality, new releases and so forth.The roadmap also outlines the features that need to be prioritized for delivery and is an important reference—not just for the developers, but for all those involved in the product development lifecycle.  For Agile teams, the product roadmap outlines the estimates of day-to-day tasks and is an important feature of the Agile product development lifecycle as it helps to follow the Agile values of early and continuous delivery of valuable software by helping the teams focus on priorities.How to Create a Product RoadmapBuilding the product roadmap is one of the steps of the product development plan. Once the product vision is created after understanding the requirements of the stakeholders, market research and analysis, the product management team gets on with creating the product roadmap.  Building a product roadmap involves five main stages: Defining the strategy: As the name suggests, the strategy must define the overall goal of the project, the vision and how it aligns to the overall business objectives. The strategy outlines how the team or the company is going to go about achieving the goal or the project mission. Reviewing and managing ideas: There may be several requests from the user, but how do you prioritise these ideas? Ideas may even come from your development team and often such ideas can lead to better and more innovative products. How would you prioritise ideas on the product roadmap? By ranking and assigning values to each idea. Once you find out the value that each idea brings in by considering estimated cost, effort and value it is easy to rank each on the product roadmap. This will help you understand which ideas are to be prioritized and will help you manage better.   Defining features and requirements: Once your strategy is fixed you can identify the features that best support your strategy. You can further split these requirements into user stories that the development teams can use to determine their day-to-day tasks.  Organizing releases and setting timeframes: Once the requirements are set, the development team can define epics and sprints and determine the dates of releases. Releases can be grouped.  Choosing a view that suits your audience: Now that your roadmap and all the elements under it have been defined, you must share it with the others on the team including the stakeholders and the management. For this you would need to choose the view for the roadmap or decide which elements you would want to display and to what detail. You must consider certain considerations while creating a view for your roadmap such as: The purpose of the roadmap The audience for the roadmap The information that will appear The time frame that the roadmap should coverBest Practices for Creating an Effective Product RoadmapWhile creating the roadmap depends on the project and the organization, there are certain best practices that teams need to follow while creating product roadmaps to ensure effectiveness and value addition. The most important prep work, before the creation roadmap, is to ensure that you have your purpose, vision and strategy right. This sets the base for everything that follows. Your roadmaps are tools that you use for communicating the objectives and milestones with different teams and parties. Keeping this in mind ensure that you create different roadmaps for different audiences. The items of your roadmap should focus more on outcomes rather than on features. Keep reviewing and updating your roadmap at the right frequency. The product roadmap should always be current and be transparent to the teams. Make sure that your roadmaps are communicated in the right way. Make sure your roadmap conveys the right timelines; timelines should be flexible while at the same time realistic to ensure accountability. Do not use your roadmap as your product backlog. Remember that the roadmap is a high-level overview of the product strategy or goal and does not need to include everyday tasks like bug fixing user support research etc into it. Make sure you have all the right data to back up the items on your roadmap. You may need this in case you are asked to justify something on the roadmap by the stakeholder, investor, or even the team members.  Web-based Tools to Create a Product RoadmapYour product roadmap is a great communication tool. This said, it also must be visually appealing and tell a story to those who are accessing and viewing it. Gone are the days when people used Excel and PowerPoint to display their roadmaps. Compared to cloud-based tools, creating roadmaps on old technologies is cumbersome and difficult to update. There are several tools available in the market to help you with creating the appropriate roadmap for your needs. Product roadmap examples available include:  Monday.com Productboard Roadmunk Trello StoriesOnBoard and more Types of audience for a product roadmapYour roadmap is a mirror to your project and sharing it will help you maintain transparency and trust with all those involved in the project. You will have to share your roadmap with several people including: Management or leadership: The C-suite of your company may want to know how the project you build aligns to the goals and business objectives of the organization.   Engineering team: The roadmap is a bible for the engineering team as they will know the scope, goal and shape the project needs to take based on the product roadmap. They will know how to go about the development by understanding the releases, features and requirements outlined in the product roadmap.   Marketing team:The marketing team will use the product roadmap to understand the product strategy and goals along with the benefits that each release or feature will bring to the customer.   Sales team:The sales team must sell the product, which is why they would need to know the benefits the product will bring into the customers. The product roadmap will be referenced by them for this purpose.The importance of tailoring your roadmap to the right audienceYou can have different views for your roadmap based on who you are going to show it to and what information you want to communicate. Your audience is primarily of two types: Internal: Members who are part of your team and organization including team members, executives, sales team etc. Each team should be given a roadmap that is specific to their requirements. The executive or managerial team for example would need data that is more strategic and to know how the product aligns with the organizational objectives. The product roadmap for the sales team would concentrate on the product value; that will help the sales team understand the value the product will bring in for the user. The development team would see a roadmap that shows them key technical aspects and deadlines for these. External: members who are not part of the internal team such as customers, investors etc form the external members. The product roadmap shown to external customers often does not include information such as deadlines or any internal process flows. It concentrates more on the advantages that the product would give the end-user. It is less strategic and more visually appealing and easy to understand.Product roadmap types and examplesThere are several types of roadmaps that are used for different projects. These roadmaps may be tailored in terms of looks and content to suit the needs of your project. Some common product roadmap types are: Strategic roadmap: As the name suggests, this roadmap communicates the strategy and the long-term initiatives that align to the organizational mission. This roadmap focuses on long term objectives, timelines and deadlines.  Now-next-later roadmap: As the name suggests, this approach breaks down the roadmap into three parts. Now-which lists the initiatives that are being worked on now; Next-that lists the initiatives that will be taken up next and finally Later that lists the initiatives that will be tackled at a later stage. This product map gives the stakeholders and the team a bird’s eye view of the roadmap and makes it easier to suggest changes or differentiate priorities.Kanban roadmap: This is an excellent roadmap for development teams who want to communicate their plans without committing to exact timelines or dates. It helps teams to group activities into buckets such as what is in the backlog, what is planned and what is in progress. Source: productboard.comRelease plan roadmap: This is typically used as an external roadmap for customers and stakeholders. It displays initiatives such as planned releases etc and does not have much technical detail.Source: productboard.comAgile/Sprint Roadmap Example  Agile is all about flexibility, better responses to customer requirements and fast releases. Agile projects can benefit a lot from creating a product roadmap that communicates the long-term objectives of the project and helps establish a balance between short term and long-term goals. The agile roadmap is a great tool for providing direction to the team to carry out their everyday tasks. There are several tools available to create product plans for agile teams that help promote agility and implement agile values.  Source: Atlassian.comThis is an example of an Agile product roadmap for an Agile product team. The initiatives are in blue, and timelines are indicated by the milestone-markers in red. Conclusion  The Product roadmap is crucial not just in understanding long term goals and objectives but also to set context to everyday tasks and make sure that the product is responsive to competition and changing business requirements. The product roadmap works across industries, organizations and teams and is a must for projects of any size. It’s a tool that can be utilised by product owners and the product development team to ensure successful projects and value delivery.  
9265
The Ultimate Guide to Product Roadmaps

Before starting any project, be it Agile, waterfal... Read More

What Is User Story Mapping?

User stories are concise descriptions of a software capability, written from the point of view of the customer or end user. A user story is an efficient way of precisely capturing the ‘who’, ‘what’ and ‘why’ of a product requirement and can be thought of as a ‘to-do’ list that guides the product development journey.In this article, we will talk about what is user story mapping, why it is important, and how and when it should be done. You will get a high-level view of story mapping, understand the core concepts involved, and learn how to bring user stories to life in your Agile projects so that your team can get the maximum benefit from this technique.What is user story mapping?User story maps are simple, lightweight representations of the product development journey in an Agile project. This method was popularised by Jeff Patton who first wrote about it in his book User Story Mapping, where he outlined how this technique could be used to help keep the focus on user needs without getting tangled up in never-ending product feature requirements.These story maps—which are changeable and keep evolving throughout the journey—enable the team to have meaningful conversations about user needs through the development process, never losing sight of the big picture.Source: nngroup.comUser-Story Mapping DefinedUser story mapping can be defined as an exercise during which product managers and development teams list out the work that will create the most value to end users, maximising customer delight.During this exercise, teams create a dynamic outline of the ways in which the customer is expected to use the product. They try to understand which steps offer the most value and prioritise the stories accordingly. The user story format is an amazingly simple, concise sentence which clearly captures the requirements:“As a [type of user], I want to [action] so that [benefit]. “ Without getting into too much detail, this format holds the essence of product interactions from a user’s perspective.Why It’s Called User-Story MappingIn the user-story map, all the activities are captured as short phrases that represent actual user actions. The first half of the user-story format, therefore, talks about what the user wants to do with the product. Next, the story is elaborated to include the key benefits as the second half of the conversation. So, this mapping method is called user-story mapping because it is cantered on the user and his or her needs. Later, the team fleshes out this simple sentence into detailed user stories that are discussed, with acceptance criteria added on, and then added to the product/sprint backlog for completion during each sprint as per priority. As we can see, the purpose behind user stories is to spark a dialogue around the solutions to user needs, from the viewpoint of the customer who will be using the product. The users are usually laypersons who are likely to be non-technical, and therefore the product must be easy to use, with an interface that is not complex and can be navigated easily. When the entire exercise is cantered on the user, the focus gets shifted to the customer’s perspective and maximises the product value in terms of user satisfaction. When and How to Create a User Story MapThe user story map is created as one of the first exercises in the product development process. It is not a rigid document, and evolves as the journey unfolds, in keeping with the spirit of Agile.  Subsequently, the user story mapping can be carried out whenever the team needs more clarity on how to improve on the first version, how to manage the backlog or when branching out in a new direction with requirements for product extensions. These are the processes involved in creating a User Story Map: 1. Start with the big pictureStart by identifying the big picture. What are the broad user applications that your product must support? Draft these big stories on cards and arrange them in the order of priority for the end user.2. Break down the bigger storiesEach of these big user activities is now broken down into smaller user tasks. Once again, keep the user in mind and prioritise these tasks from the user’s perspective. This is now the backbone of your User Story Map.3. Look for the gapsIt helps to walk through the map with your customers or stakeholders. Is there anything you’ve missed out? They will help you to fill in the gaps.4. Start prioritisingRemember, at this stage it is still a high-level map and is highly likely to get changed down the line. Put the user tasks and subtasks within each activity into the order of importance.5. Select your first releaseFrom all the tasks listed, choose the ones that will go into your first version, which will be the MVP or Minimum Viable Product for your very first release.Once you have the ball rolling, get started on your first release and then keep the momentum alive by planning subsequent releases in the same way. As you go along, you will be re-ordering the user story map, aligning subsequent stories horizontally to match your timeline, and creating order out of chaos.What are some benefits of user story mapping?As we have already seen, user story mapping is a systematic and highly efficient way of working out task priorities. When done right, it offers significant benefits that help teams build products that customers will love. Lays the focus on the userAny product must be built with the end user in mind. User story mapping shines the spotlight on the user’s needs and tells the story from the point of view of the user. It maps out the user experience and helps to emphasize the efforts that will lead to the best outcomes, creating an outside-in approach rather than the traditional inside-out way of working. Sets priorities By breaking down the bigger picture into smaller tasks, while always keeping the vision in mind, teams can decide what is important and what needs to get built first. A holistic visualisation of tasks helps to put priorities in the right perspective. Teams will organize releases around the delivery of maximum value and push items of lower value to the bottom of the backlog. Gives clarity on requirements When requirements are laid out in the form of strong user stories, teams get clarity on what needs to be done. They can get a visual representation of how the larger work items can get broken down into smaller tasks and understand which are the tasks that club together to make one feature. Delivers value quicklyWork gets grouped together into iterations, and releases are planned around delivery of value. By working on the more important tasks faster, teams can deliver product increments more rapidly, get feedback early and maximise customer value. Mitigates risks earlyRisks and dependencies get exposed early in the development journey, and developers can plan to mitigate these risks and iron out potential obstacles to smooth progress of work. Early planning can reduce dependencies and streamline the tasks more effectively. Builds team collaborationIn the end, the project progress will depend on how well the team works together. User story mapping is a team building exercise where the team members get a shared view of the customer experience and work together to map out tasks. Team collaboration is built through meaningful conversations.  Who should participate in user story mapping?User story mapping is one of the most important exercises during the planning stage. It brings cross functional teams into better alignment and helps them work collaboratively toward building the best possible product in the market. It is important that all teams whose work will contribute toward successful delivery should participate in the dialogue.Team members from Engineering, UX/design, Product management, Sales, Customer support, Finance, Ops / IT, Legal and Marketing teams can take part in this exercise and give their valuable inputs. How does user story mapping work?Teams can use planning software like Lucid chart, or even simple physical resources like a chart or a section of wall with sticky notes, to build the story map. Once they have decided on the medium to use, they can work on the following steps:1. Define the problemWhat is the problem that is solved by your product? This is your product goal, and it’s important to clearly define it at the outset. Once the goal is defined, the work that is to be done to achieve this goal can be mapped.2. Understand the target audienceAny user story exercise starts with creating a persona as the end user. There could be several distinct categories of users, and all must be discussed. Each target persona will have a unique way of interacting with your product. Once the personas are understood, the user stories can be built from the perspective of each of these target users. This is an important aspect, as efforts are not wasted in building features that may not be important to any of these end users.  Source: storiesonboard.com3. Map user interactionsEach user will use the product through a series of activities related to the product. Also known as themes, these activities are what will form the structural outline of the user story map. As an example, when buying an online service, users may wish to search a list of service providers, view their online rankings, check prices, and then put the chosen service item into the cart and complete the payment. These will comprise the main stories, and each will then be broken down into smaller tasks.4. Break down the storiesEach of the major stories is then fleshed out into smaller activities, which are then written down in the format: ‘As a _______, I want to _________, so that _______.’ For instance, this could be something like: As a subscriber of Amazon music, I want to search for hip-hop music, so that I can make a playlist. 5. Set priorities and decide the flowOnce your bigger themes and user stories are mapped out, the next step is to prioritise and set the flow. Always rank them in such a way that the most urgent tasks are on the top of the list. The flow of tasks is usually always from left to right, and top to down. The visual representation of the user story mapping is already taking a visual form, helping teams to decide on the sequence and importance of work to be done.6. Look for gaps and dependenciesThis is a crucial step that will help to identify any bottlenecks that could impede progress. For instance, for task C to be completed, task A must first be finished. But for task C to even begin, there might be an interim task B that has not even been listed on the chart. In this way, all the missing gaps can be filled, and dependencies noted. Teams could also discuss workarounds if any if a dependency is found for which they do not have a resource now.7. Schedule sprints and releasesThis is the stage where teams create action plans and schedules. Now that they know the quantum of work that is needed, they can gauge the work that is needed to deliver the most value in the shortest time and group activities together into sprints and releases, always keeping user priorities in the forefront.What are some challenges of user story mapping?While user story mapping can yield great results when done the right way, it comes with its own set of challenges for teams that are inadequately prepared. Look out for these challenges:No personaThere might be instances where there is lack of clarity on who the end user is. In such cases, imagine a persona who represents the most possible end user, and work with this characterisation. Lack of clarity on the end goalThe product goal is the solution to a problem that exists and is the reason for building the product. When there is lack of clarity on the problem itself, then the team could end up building stories on the wrong goals. This will waste time, money and effort and could result in some unnecessary rework and lack of motivation. Not using collaborative software Smaller teams who are co-located might find it makes sense to do their planning using sticky notes on a wall, or markers on a whiteboard. What happens if someone cleans the whiteboard by mistake, or some of the notes fall off and are swept away? All the planning would have been in vain! Repetitions and reworkThe stories in a user story map might need to be rewritten in the form of a product backlog, which involves some rework. Instead, use collaborative tools that map progress and automatically keep records of the work done. An added advantage of using the right tools is that distributed teams can also participate in the planning and tracking of goals. What happens after user story mapping is completed?Once the user story mapping exercise is completed, teams will schedule their list of stories as per priority into sprints and releases. This forms the outline of the product roadmap, which will need to be shared with management and other teams that did not participate to ensure consensus. At this point, any teams which were not able to participate in the planning so far may give their inputs as well. The final user story mapping could be transferred to a shared software tool so that it can be viewed by all teams concerned in real time. Engineering team members will add technical specs and detail out their acceptance criteria, so that the Definition of Done for each story is known to all teams. This story map is never static but is always a work in progress. Estimates could be revised, schedules may be moved up or down, and parallel branches of the product might need to be added. At any time, the story map reflects the work to be done.What agile values and principles does story mapping support?Story mapping is an especially useful and productive tool that helps product managers and development teams to maximise customer value through an adaptive, iterative approach. At each stage, they will find plenty of opportunities to learn and improve themselves and the processes. As such, story mapping supports these values of the Agile Manifesto:  Customer collaboration over contract negotiation: The best results are obtained when many heads are put together to collaborate on the product. Each person will input their expertise, and the collaborative efforts are always far better than efforts of a few. User story mapping is an exercise in team collaboration. Responding to change over following a plan: Any Agile project is, by its very nature, adaptive and is designed to factor in all emerging requirements easily. When a new user story is added, or an existing one is changed, it becomes very easy to visualise the implications on the rest of the stories. User-Story Mapping vs. Customer-Journey MappingWhile user-story mapping and customer-journey mapping sound remarkably similar, there is a subtle difference in the emphasis. A customer journey map takes the perspective of the user and shows their interactions with the product and the steps taken to achieve an objective. It will also think about the user’s thoughts and experiences during this journey. On the other hand, a user story is mapped from the point of view of the product, as the user interacts with it. It will guide the planning of features and functionality, as the product tries to solve the user’s problems.  Both will work very well when combined to achieve all the product goals and create and maximise customer delight. What Problems Does Story Mapping Solve?Story mapping solves the problems that arise due to lack of clarity in defining the requirements and tasks. It helps teams to comprehend user needs, set priorities for tasks, and collaborate with each other effectively. It helps to keep the focus on what is important- the end goals- so that the team does not get side-tracked into doing less important tasks. Once the user stories are mapped, the final set of acceptance criteria can be drawn up, schedules can be created, and a roadmap can be outlined.How Do You Use Story Mapping to Prioritize Roadmap Initiatives?User story maps give all the inputs needed to create a product roadmap. All the features are listed out in detail, broken down into user stories and basic priorities are set. All that remains is to group the features that deliver maximum value in the quickest time together, and schedule releases based on the team’s capabilities.  Here is how to go about this: Arrange the items as per priority and assign each item story points to estimate the effort required for completion. Increase efficiency by clustering items that should be built together as they have dependencies on each other. This will help to determine how much of work will fit into each release, and you can then plan releases and sprints accordingly. You could decide to go with an equal number of items per release, or regroup based on the size, complexity, or importance of items. Once your tasks are decided for each release, map them to successful outcomes. Remember, at the end of each sprint you should have a potentially shippable increment that delivers a measurable amount of product value to highlight to stakeholders. If you have a feature that is too large to be completed in one single sprint, build the bare structure first, fleshing it out in the next iteration. This way, you can quickly get the functionality out, but continue to improve on it and incorporate user feedback.  Try to avoid a sprint where there is no actual value that is delivered to the end user, even though some progress has been made.Conclusion Anyone who has created user stories knows that this takes time and effort, and the best results come with experience. They allow teams to see the bigger picture, keeping the user at the core of all development progress. When done the right way, user story mapping promotes meaningful collaboration, enables quicker feedback and faster deliveries, and results in creating high-quality product features that most suit customer needs. 
9566
What Is User Story Mapping?

User stories are concise descriptions of a softwar... Read More

How To Use T-Shirt Sizing as a Product Owner to Estimate Delivery

The beauty of Agile is that it is not prescriptive. Once organizations have understood the crux of Agile, they can tailor it to suit their needs and define processes that will ensure maximum output. Agile estimation is one such example. These simple, yet effective, techniques set the tone for the entire Agile project and help teams navigate complex projects easily.  T shirt sizing in agile is a relative estimation technique that helps for long term effective planning. In this blog we attempt to deep dive into T-shirt sizing estimation and try to understand its benefits and drawbacks.What is T-shirt sizing estimation?Agile often starts with a high-level estimate or a macro view of the project. This helps teams and stakeholders come to a long-term plan for the project. One of the ways that Agile does this high-level estimate is though T-shirt sizing agile, in other words estimating story points using a relative estimation technique.  T-shirt sizing, as mentioned before, is a relative project estimation technique to estimate what a project will need in terms of time, budget, and energy. It is a good technique for teams that are new to agile and want to perform a relative estimation of the project. T-shirt size planning can be further broken down into story points for sprint planning. Story points can be broken down further into hours for sprint execution. While t-shirt sizing is great for release planning and defining project roadmap, story point estimates are more accurate and better for sprint planning.  What is a story point? A Story point is a unit of measure for expressing an estimate for the overall effort needed to complete a particular user story, sprint, or product backlog item. While in traditional project management  methods the effort is conveyed in a time format like days, weeks or months, Agile uses story points to provide estimates and these can be provided by considering the amount of work, the complexity of work and associated risks. This is where story points differ from estimating in person-hours which may not consider the complexity or risk that may delay the task. Also, story point estimation is more flexible and is perfect for high level estimation.T-shirt sizes for introducing relative estimationChoosing a t-shirt when you walk into a store is simple. You have clearly labelled sizes like S, M, L, XL and all you need to do is pick one. While this may be a relative sizing and each T-shirt size can fit a range of shoulder sizes, it is much easier than having numerical t-shirt sizes like 38, 40, 42 etc.  Similarly, for agile projects, teams can classify items or user stories as extra-small, small, medium, large, extra-large, or double extra-large. This T-shirt sizing estimation eliminates the numerical score associated with story points and helps developers to be more flexible and dynamic about the effort associated with a story. Depending on the size of the task, the developers will assign a t-shirt size. It’s important that all developers arrive at a consensus on the T-shirt size assigned to each task. The stories are all placed in S, M, L, XL buckets and the time taken to complete all the tasks in the buckets is estimated. Teams can get a relative understanding of how big or small the story is.The downside of T-shirt sizing PBIsThe problem with T-shirt's sizing is that it is a relative estimate, so teams would only get a ballpark figure or a range and not an exact estimate of effort needed to complete a user story.Also, since product backlog increments or PBIs are indicated in terms of T-shirts sizes, it would be difficult to estimate or review how much work is done. Like for example, your report may show that for this sprint you have completed 2 small, 4 medium and 3 large PBIs. This may make it difficult to measure the velocity of work.Benefits and pitfallsBenefits:Helps in quick estimates for substantial number of itemsHelps teams new to agile better perform estimationsIs flexible as estimation does not change even if velocity changesGives estimates in relative termsIs easy and effective for first level of estimating and large backlogs.Pitfalls:Relative estimates are not absoluteMay need to be converted to numerical value if velocity needs to be calculatedAre not uniform. One team’s t-shirt estimate may be different from that of another team.Delivery planning with T-shirt estimatesThe t-shirt sizing is a great way of providing initial estimates and can be used as a first round of estimating, providing stakeholders and the team with a relative or broad idea of time and effort required for the project.As mentioned above, it is often the first round of planning and starts with the project being split into high level epics which may be given t-shirt sizes. You may give an estimate range for epic size in a number of days.For example:Small = 1–4 daysMedium = 5–10 daysLarge = 10–20 daysYou can use this estimate and suppose that your first delivery of the product will take around 26-54 days.The second round of planningOnce you have created a broad estimate it is time to do the second round of planning and develop the product backlog items corresponding to epics. The epics can be further broken down into user stories for sprints. Each PBI can be estimated with story points to get a more accurate estimate for the PBIs.How to use T –shirt sizing to determine project scopeT-shirt estimation is a great way to understand the overall scope of your project. For example, a shopping list that is a small t-shirt size would mean buying a couple of items like a toothbrush and a cola, whereas a large t-shirt size idea would be buying fifty or more items from a shopping list. So, slotting these various tasks into t-shirt sizes will help the team understand the overall scope of the project and what must be accomplished. It helps to understand the effort required by each team member to accomplish the task.Getting the Right Fit: The Do’s and Don'tsT-shirt sizing, just like Agile, is not a one-size fits all method. Teams must figure out how to use it depending on their project and keeping in mind past projects and retrospectives.There are some do’s and don’ts for t-shirt sizing that must be followed for success:Get the bigger picture: You can think big and dream during this process. Your result will be a rough estimate so you can let yourself go.Make sure to stick to the scope: It is easy to get derailed with so many ideas coming in from so many people. But make sure to keep your eye on the project goal and ensure that the sizing is getting you closer to the goal.Do not have too many sizes: This exercise is supposed to simplify your decision-making process, so there is no point in complicating it by adding too many t-shirt sizes.Do not get rigid with T-shirt labels: You can get creative with the names if you don’t want t-shirt names. Go for fruit names if you find it better! You can estimate in terms of a grape for the smallest stories and a pineapple for the larger ones. Alternatively, think of animals if your team likes them better. You can have everything from rabbits to giraffes to define your epics and sprints.Assigning velocity for product backlog itemsDevelopment teams work around this by assigning each size a numerical value such S=1, M=3, L=5, XL=8. Assigning numerical values makes it easier to calculate the velocity. So, if team has completed 2 Small, 4 Medium and 3 Large PBIs then the velocity can be calculated as:Velocity= S+M+L= (2*1)+(4*3)+(3*5)=29T-Shirt sizing is fastT-shirt estimation allows an extremely fast, almost instant estimation with basic information. Compared to more absolute types of estimation that require more information from stakeholders and users and can result in considerable time consumption and effort, t-shirt sizing is quick and saves close to 80% times in some cases.How does T-shirt sizing work?T-shirt sizing starts off with the portfolio management team defining the size of the project, and they categorize the project as being extra small, small, medium, large, extra-large etc. The product owner first gets together with the stakeholders and defines a few high-level epics. The epics are given t-shirt sizes based on their perceived complexity. The development team also uses historical data from previous projects to classify tasks into different sized buckets.T-shirt sizing is a great option for teams new to the whole estimating business. It is fast and simple, and teams can use it till they learn the ropes of the more accurate forms of estimation. Splitting projects into generalized buckets helps the team to break down complex tasks, helps in communication and allows the team to look at a long-term roadmap for the project. When done correctly, t-shirt sizing can boost productivity and save the team a whole lot of effort.
6605
How To Use T-Shirt Sizing as a Product Owner to Es...

The beauty of Agile is that it is not prescriptive... Read More

Useful links