\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 2 1 2
\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 2 1 2
\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 2 1 2
\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 2 1 2
\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 1 of 2 1 2
\n
\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n
(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n
\n\n\n\n

Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


\n\n\n\n

Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


\n\n\n\n

Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


\n\n\n\n

Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n

Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


\n\n\n\n

Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

Suggested Solution:<\/strong><\/p>\n\n\n\n

Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

\n
  • During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

    Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

    She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

    She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

    You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


    \n\n\n\n

    Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

    Suggested Solution:<\/strong><\/p>\n\n\n\n

    While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

    Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

    1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

    2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

    3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

    These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

    Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

    She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

    What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

    Suggested Solution:<\/strong><\/p>\n\n\n\n

    Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

    In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

    The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

    Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

    (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

    In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

    A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

    Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

    Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

    Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

    Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

    \"\"<\/a><\/figure>\n\n\n\n

    Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

    If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

    As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

    This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

    As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

    As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

    \n
  • Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
  • During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

    Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

    She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

    She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

    You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


    \n\n\n\n

    Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

    Suggested Solution:<\/strong><\/p>\n\n\n\n

    While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

    Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

    1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

    2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

    3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

    These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

    Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

    She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

    What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

    Suggested Solution:<\/strong><\/p>\n\n\n\n

    Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

    In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

    The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

    Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

    (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

    In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

    A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

    Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

    Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

    Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

    Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

    \"\"<\/a><\/figure>\n\n\n\n

    Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

    If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

    As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

    This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

    As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

    As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

    \n
      \n
    1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
    2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

      Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

      She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

      She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

      You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


      \n\n\n\n

      Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

      Suggested Solution:<\/strong><\/p>\n\n\n\n

      While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

      Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

      1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

      2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

      3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

      These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

      Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

      She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

      What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

      Suggested Solution:<\/strong><\/p>\n\n\n\n

      Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

      In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

      The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

      Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

      (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

      In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

      A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

      Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

      Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

      Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

      Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

      \"\"<\/a><\/figure>\n\n\n\n

      Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

      If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

      As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

      This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

      As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

      As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

      \n

      Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

        \n
      1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
      2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

        Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

        She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

        She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

        You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


        \n\n\n\n

        Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

        Suggested Solution:<\/strong><\/p>\n\n\n\n

        While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

        Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

        1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

        2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

        3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

        These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

        Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

        She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

        What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

        Suggested Solution:<\/strong><\/p>\n\n\n\n

        Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

        In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

        The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

        Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

        (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

        In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

        A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

        Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

        Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

        Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

        Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

        \"\"<\/a><\/figure>\n\n\n\n

        Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

        If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

        As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

        This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

        As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

        As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

        \n

        This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

        Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

          \n
        1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
        2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

          Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

          She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

          She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

          You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


          \n\n\n\n

          Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

          Suggested Solution:<\/strong><\/p>\n\n\n\n

          While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

          Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

          1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

          2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

          3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

          These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

          Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

          She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

          What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

          Suggested Solution:<\/strong><\/p>\n\n\n\n

          Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

          In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

          The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

          Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

          (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

          In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

          A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

          Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

          Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

          Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

          Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

          \"\"<\/a><\/figure>\n\n\n\n

          Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

          If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

          As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

          This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

          As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

          As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

          \n

          After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

          This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

          Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

            \n
          1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
          2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

            Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

            She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

            She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

            You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


            \n\n\n\n

            Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

            Suggested Solution:<\/strong><\/p>\n\n\n\n

            While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

            Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

            1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

            2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

            3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

            These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

            Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

            She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

            What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

            Suggested Solution:<\/strong><\/p>\n\n\n\n

            Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

            In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

            The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

            Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

            (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

            In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

            A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

            Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

            Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

            Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

            Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

            \"\"<\/a><\/figure>\n\n\n\n

            Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

            If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

            As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

            This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

            As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

            As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

            \n

            Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

            After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

            This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

            Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

              \n
            1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
            2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

              Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

              She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

              She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

              You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


              \n\n\n\n

              Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

              Suggested Solution:<\/strong><\/p>\n\n\n\n

              While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

              Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

              1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

              2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

              3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

              These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

              Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

              She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

              What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

              Suggested Solution:<\/strong><\/p>\n\n\n\n

              Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

              In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

              The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

              Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

              (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

              In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

              A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

              Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

              Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

              Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

              Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

              \"\"<\/a><\/figure>\n\n\n\n

              Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

              If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

              As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

              This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

              As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

              As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

              \n

              Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

              Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

              After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

              This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

              Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                \n
              1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
              2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                \n\n\n\n

                Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                Suggested Solution:<\/strong><\/p>\n\n\n\n

                While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                Suggested Solution:<\/strong><\/p>\n\n\n\n

                Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                \"\"<\/a><\/figure>\n\n\n\n

                Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                \n

                This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                  \n
                1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                  Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                  She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                  She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                  You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                  \n\n\n\n

                  Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                  While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                  Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                  1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                  2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                  3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                  These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                  Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                  She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                  What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                  Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                  In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                  The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                  Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                  (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                  In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                  A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                  Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                  Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                  Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                  Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                  \"\"<\/a><\/figure>\n\n\n\n

                  Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                  If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                  As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                  This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                  As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                  As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                  \n

                  Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                  This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                  Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                  Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                  After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                  This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                  Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                    \n
                  1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                  2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                    Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                    She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                    She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                    You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                    \n\n\n\n

                    Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                    While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                    Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                    1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                    2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                    3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                    These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                    Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                    She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                    What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                    Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                    In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                    The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                    Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                    (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                    In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                    A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                    Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                    Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                    Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                    Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                    \"\"<\/a><\/figure>\n\n\n\n

                    Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                    If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                    As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                    This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                    As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                    As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                    \n

                    The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                    Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                    This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                    Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                    Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                    After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                    This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                    Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                      \n
                    1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                    2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                      Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                      She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                      She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                      You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                      \n\n\n\n

                      Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                      While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                      Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                      1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                      2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                      3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                      These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                      Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                      She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                      What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                      Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                      In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                      The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                      Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                      (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                      In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                      A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                      Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                      Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                      Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                      Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                      \"\"<\/a><\/figure>\n\n\n\n

                      Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                      If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                      As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                      This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                      As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                      As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                      \n

                      In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                      The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                      Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                      This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                      Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                      Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                      After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                      This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                      Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                        \n
                      1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                      2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                        Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                        She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                        She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                        You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                        \n\n\n\n

                        Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                        While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                        Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                        1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                        2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                        3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                        These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                        Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                        She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                        What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                        Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                        In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                        The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                        Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                        (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                        In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                        A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                        Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                        Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                        Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                        Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                        \"\"<\/a><\/figure>\n\n\n\n

                        Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                        If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                        As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                        This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                        As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                        As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                        \n

                        What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                        In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                        The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                        Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                        This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                        Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                        Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                        After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                        This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                        Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                          \n
                        1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                        2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                          Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                          She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                          She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                          You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                          \n\n\n\n

                          Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                          While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                          Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                          1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                          2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                          3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                          These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                          Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                          She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                          What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                          Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                          In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                          The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                          Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                          (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                          In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                          A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                          Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                          Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                          Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                          Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                          \"\"<\/a><\/figure>\n\n\n\n

                          Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                          If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                          As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                          This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                          As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                          As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                          \n

                          Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                          What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                          In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                          The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                          Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                          This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                          Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                          Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                          After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                          This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                          Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                            \n
                          1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                          2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                            Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                            She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                            She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                            You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                            \n\n\n\n

                            Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                            While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                            Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                            1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                            2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                            3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                            These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                            Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                            She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                            What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                            Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                            In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                            The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                            Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                            (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                            In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                            A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                            Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                            Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                            Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                            Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                            \"\"<\/a><\/figure>\n\n\n\n

                            Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                            If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                            As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                            This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                            As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                            As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                            \n

                            The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                            Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                            What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                            In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                            The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                            Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                            This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                            Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                            Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                            After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                            This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                            Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                              \n
                            1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                            2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                              Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                              She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                              She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                              You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                              \n\n\n\n

                              Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                              While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                              Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                              1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                              2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                              3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                              These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                              Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                              She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                              What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                              Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                              In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                              The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                              Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                              (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                              In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                              A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                              Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                              Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                              Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                              Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                              \"\"<\/a><\/figure>\n\n\n\n

                              Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                              If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                              As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                              This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                              As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                              As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                              \n

                              Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                              The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                              Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                              What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                              In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                              The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                              Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                              This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                              Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                              Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                              After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                              This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                              Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                \n
                              1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                              2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                \n\n\n\n

                                Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                \"\"<\/a><\/figure>\n\n\n\n

                                Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                \n

                                I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                  \n
                                1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                  Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                  She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                  She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                  You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                  \n\n\n\n

                                  Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                  While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                  Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                  1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                  2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                  3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                  These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                  Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                  She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                  What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                  Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                  In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                  The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                  Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                  (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                  In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                  A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                  Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                  Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                  Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                  Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                  \"\"<\/a><\/figure>\n\n\n\n

                                  Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                  If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                  As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                  This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                  As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                  As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                  \n

                                  The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                  Challenges in looking for and creating innovation when teams are distributed.
                                  Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                  I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                  Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                  The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                  Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                  What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                  In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                  The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                  Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                  This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                  Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                  Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                  After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                  This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                  Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                    \n
                                  1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                  2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                    Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                    She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                    She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                    You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                    \n\n\n\n

                                    Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                    While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                    Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                    1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                    2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                    3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                    These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                    Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                    She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                    What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                    Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                    In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                    The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                    Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                    (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                    In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                    A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                    Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                    Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                    Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                    Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                    \"\"<\/a><\/figure>\n\n\n\n

                                    Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                    If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                    As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                    This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                    As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                    As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                    \n

                                    In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                    The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                    Challenges in looking for and creating innovation when teams are distributed.
                                    Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                    I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                    Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                    The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                    Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                    What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                    In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                    The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                    Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                    This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                    Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                    Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                    After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                    This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                    Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                      \n
                                    1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                    2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                      Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                      She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                      She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                      You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                      \n\n\n\n

                                      Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                      While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                      Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                      1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                      2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                      3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                      These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                      Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                      She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                      What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                      Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                      In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                      The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                      Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                      (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                      In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                      A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                      Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                      Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                      Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                      Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                      \"\"<\/a><\/figure>\n\n\n\n

                                      Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                      If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                      As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                      This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                      As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                      As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                      \n

                                      Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                      In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                      The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                      Challenges in looking for and creating innovation when teams are distributed.
                                      Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                      I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                      Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                      The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                      Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                      What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                      In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                      The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                      Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                      This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                      Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                      Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                      After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                      This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                      Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                        \n
                                      1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                      2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                        Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                        She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                        She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                        You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                        \n\n\n\n

                                        Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                        While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                        Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                        1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                        2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                        3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                        These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                        Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                        She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                        What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                        Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                        In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                        The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                        Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                        (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                        In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                        A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                        Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                        Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                        Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                        Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                        \"\"<\/a><\/figure>\n\n\n\n

                                        Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                        If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                        As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                        This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                        As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                        As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                        \n

                                        Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                        Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                        In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                        The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                        Challenges in looking for and creating innovation when teams are distributed.
                                        Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                        I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                        Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                        The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                        Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                        What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                        In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                        The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                        Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                        This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                        Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                        Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                        After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                        This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                        Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                          \n
                                        1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                        2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                          Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                          She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                          She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                          You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                          \n\n\n\n

                                          Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                          While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                          Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                          1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                          2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                          3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                          These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                          Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                          She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                          What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                          Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                          In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                          The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                          Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                          (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                          In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                          A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                          Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                          Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                          Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                          Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                          \"\"<\/a><\/figure>\n\n\n\n

                                          Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                          If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                          As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                          This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                          As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                          As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                          \n

                                          Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                          Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                          Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                          In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                          The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                          Challenges in looking for and creating innovation when teams are distributed.
                                          Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                          I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                          Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                          The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                          Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                          What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                          In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                          The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                          Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                          This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                          Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                          Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                          After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                          This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                          Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                            \n
                                          1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                          2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                            Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                            She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                            She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                            You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                            \n\n\n\n

                                            Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                            While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                            Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                            1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                            2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                            3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                            These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                            Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                            She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                            What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                            Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                            In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                            The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                            Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                            (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                            In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                            A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                            Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                            Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                            Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                            Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                            \"\"<\/a><\/figure>\n\n\n\n

                                            Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                            If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                            As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                            This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                            As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                            As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                            \n

                                            Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                            Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                            Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                            Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                            In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                            The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                            Challenges in looking for and creating innovation when teams are distributed.
                                            Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                            I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                            Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                            The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                            Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                            What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                            In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                            The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                            Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                            This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                            Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                            Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                            After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                            This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                            Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                              \n
                                            1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                            2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                              Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                              She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                              She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                              You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                              \n\n\n\n

                                              Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                              While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                              Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                              1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                              2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                              3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                              These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                              Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                              She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                              What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                              Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                              In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                              The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                              Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                              (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                              In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                              A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                              Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                              Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                              Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                              Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                              \"\"<\/a><\/figure>\n\n\n\n

                                              Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                              If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                              As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                              This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                              As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                              As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                              \n
                                              \"LEVER\"<\/a><\/figure>\n\n\n\n

                                              Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                              Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                              Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                              Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                              In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                              The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                              Challenges in looking for and creating innovation when teams are distributed.
                                              Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                              I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                              Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                              The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                              Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                              What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                              In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                              The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                              Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                              This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                              Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                              Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                              After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                              This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                              Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                \n
                                              1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                              2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                \n\n\n\n

                                                Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                \"\"<\/a><\/figure>\n\n\n\n

                                                Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                \n

                                                An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                Challenges in looking for and creating innovation when teams are distributed.
                                                Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                  \n
                                                1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                  Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                  She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                  She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                  You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                  \n\n\n\n

                                                  Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                  While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                  Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                  1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                  2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                  3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                  These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                  Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                  She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                  What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                  Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                  In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                  The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                  Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                  (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                  In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                  A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                  Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                  Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                  Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                  Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                  \"\"<\/a><\/figure>\n\n\n\n

                                                  Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                  If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                  As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                  This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                  As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                  As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                  \n

                                                  When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                  The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                  An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                  \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                  Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                  Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                  Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                  Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                  In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                  The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                  Challenges in looking for and creating innovation when teams are distributed.
                                                  Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                  I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                  Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                  The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                  Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                  What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                  In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                  The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                  Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                  This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                  Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                  Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                  After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                  This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                  Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                    \n
                                                  1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                  2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                    Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                    She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                    She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                    You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                    \n\n\n\n

                                                    Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                    While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                    Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                    1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                    2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                    3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                    These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                    Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                    She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                    What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                    Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                    In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                    The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                    Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                    (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                    In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                    A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                    Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                    Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                    Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                    Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                    \"\"<\/a><\/figure>\n\n\n\n

                                                    Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                    If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                    As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                    This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                    As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                    As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                    \n

                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                    When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                    The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                    An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                    \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                    Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                    Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                    Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                    Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                    In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                    The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                    Challenges in looking for and creating innovation when teams are distributed.
                                                    Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                    I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                    Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                    The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                    Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                    What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                    In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                    The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                    Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                    This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                    Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                    Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                    After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                    This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                    Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                      \n
                                                    1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                    2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                      Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                      She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                      She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                      You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                      \n\n\n\n

                                                      Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                      While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                      Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                      1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                      2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                      3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                      These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                      Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                      She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                      What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                      Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                      In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                      The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                      Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                      (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                      In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                      A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                      Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                      Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                      Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                      Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                      \"\"<\/a><\/figure>\n\n\n\n

                                                      Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                      If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                      As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                      This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                      As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                      As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                      \n

                                                      How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                      When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                      The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                      An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                      \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                      Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                      Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                      Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                      Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                      In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                      The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                      Challenges in looking for and creating innovation when teams are distributed.
                                                      Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                      I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                      Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                      The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                      Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                      What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                      In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                      The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                      Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                      This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                      Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                      Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                      After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                      This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                      Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                        \n
                                                      1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                      2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                        Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                        She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                        She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                        You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                        \n\n\n\n

                                                        Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                        While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                        Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                        1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                        2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                        3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                        These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                        Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                        She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                        What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                        Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                        In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                        The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                        Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                        (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                        In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                        A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                        Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                        Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                        Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                        Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                        \"\"<\/a><\/figure>\n\n\n\n

                                                        Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                        If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                        As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                        This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                        As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                        As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                        \n

                                                        In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                        How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                        When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                        The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                        An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                        \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                        Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                        Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                        Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                        Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                        In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                        The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                        Challenges in looking for and creating innovation when teams are distributed.
                                                        Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                        I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                        Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                        The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                        Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                        What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                        In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                        The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                        Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                        This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                        Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                        Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                        After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                        This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                        Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                          \n
                                                        1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                        2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                          Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                          She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                          She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                          You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                          \n\n\n\n

                                                          Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                          While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                          Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                          1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                          2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                          3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                          These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                          Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                          She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                          What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                          Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                          In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                          The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                          Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                          (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                          In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                          A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                          Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                          Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                          Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                          Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                          \"\"<\/a><\/figure>\n\n\n\n

                                                          Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                          If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                          As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                          This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                          As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                          As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                          \n

                                                          The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                          In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                          How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                          When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                          The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                          An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                          \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                          Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                          Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                          Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                          Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                          In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                          The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                          Challenges in looking for and creating innovation when teams are distributed.
                                                          Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                          I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                          Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                          The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                          Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                          What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                          In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                          The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                          Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                          This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                          Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                          Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                          After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                          This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                          Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                            \n
                                                          1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                          2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                            Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                            She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                            She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                            You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                            \n\n\n\n

                                                            Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                            While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                            Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                            1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                            2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                            3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                            These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                            Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                            She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                            What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                            Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                            In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                            The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                            Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                            (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                            In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                            A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                            Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                            Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                            Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                            Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                            \"\"<\/a><\/figure>\n\n\n\n

                                                            Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                            If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                            As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                            This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                            As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                            As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                            \n

                                                            Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                            The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                            In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                            How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                            When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                            The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                            An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                            \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                            Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                            Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                            Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                            Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                            In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                            The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                            Challenges in looking for and creating innovation when teams are distributed.
                                                            Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                            I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                            Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                            The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                            Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                            What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                            In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                            The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                            Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                            This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                            Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                            Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                            After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                            This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                            Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                              \n
                                                            1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                            2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                              Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                              She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                              She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                              You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                              \n\n\n\n

                                                              Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                              While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                              Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                              1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                              2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                              3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                              These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                              Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                              She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                              What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                              Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                              In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                              The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                              Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                              (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                              In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                              A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                              Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                              Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                              Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                              Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                              \"\"<\/a><\/figure>\n\n\n\n

                                                              Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                              If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                              As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                              This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                              As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                              As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                              \n

                                                              Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                              Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                              The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                              In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                              How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                              When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                              The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                              An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                              \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                              Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                              Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                              Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                              Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                              In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                              The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                              Challenges in looking for and creating innovation when teams are distributed.
                                                              Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                              I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                              Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                              The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                              Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                              What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                              In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                              The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                              Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                              This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                              Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                              Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                              After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                              This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                              Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                \n
                                                              1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                              2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                \n\n\n\n

                                                                Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                \"\"<\/a><\/figure>\n\n\n\n

                                                                Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                \n

                                                                3. Generate multiple options for the same problem
                                                                Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                Challenges in looking for and creating innovation when teams are distributed.
                                                                Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                  \n
                                                                1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                  Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                  She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                  She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                  You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                  \n\n\n\n

                                                                  Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                  While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                  Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                  1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                  2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                  3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                  These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                  Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                  She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                  What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                  Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                  In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                  The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                  Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                  (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                  In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                  A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                  Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                  Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                  Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                  Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                  \"\"<\/a><\/figure>\n\n\n\n

                                                                  Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                  If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                  As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                  This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                  As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                  As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                  \n

                                                                  2. Focus on framing the problem
                                                                  Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                  3. Generate multiple options for the same problem
                                                                  Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                  This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                  Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                  Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                  The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                  In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                  How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                  When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                  The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                  An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                  \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                  Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                  Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                  Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                  Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                  In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                  The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                  Challenges in looking for and creating innovation when teams are distributed.
                                                                  Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                  I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                  Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                  The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                  Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                  What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                  In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                  The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                  Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                  This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                  Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                  Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                  After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                  This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                  Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                    \n
                                                                  1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                  2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                    Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                    She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                    She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                    You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                    \n\n\n\n

                                                                    Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                    While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                    Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                    1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                    2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                    3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                    These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                    Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                    She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                    What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                    Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                    In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                    The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                    Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                    (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                    In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                    A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                    Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                    Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                    Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                    Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                    \"\"<\/a><\/figure>\n\n\n\n

                                                                    Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                    If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                    As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                    This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                    As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                    As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                    \n

                                                                    1. Build your persona well
                                                                    Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                    2. Focus on framing the problem
                                                                    Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                    3. Generate multiple options for the same problem
                                                                    Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                    This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                    Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                    Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                    The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                    In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                    How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                    When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                    The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                    An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                    \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                    Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                    Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                    Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                    Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                    In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                    The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                    Challenges in looking for and creating innovation when teams are distributed.
                                                                    Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                    I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                    Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                    The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                    Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                    What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                    In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                    The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                    Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                    This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                    Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                    Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                    After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                    This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                    Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                      \n
                                                                    1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                    2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                      Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                      She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                      She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                      You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                      \n\n\n\n

                                                                      Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                      While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                      Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                      1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                      2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                      3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                      These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                      Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                      She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                      What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                      Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                      In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                      The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                      Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                      (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                      In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                      A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                      Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                      Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                      Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                      Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                      \"\"<\/a><\/figure>\n\n\n\n

                                                                      Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                      If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                      As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                      This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                      As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                      As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                      \n

                                                                      We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                      1. Build your persona well
                                                                      Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                      2. Focus on framing the problem
                                                                      Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                      3. Generate multiple options for the same problem
                                                                      Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                      This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                      Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                      Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                      The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                      In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                      How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                      When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                      The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                      An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                      \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                      Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                      Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                      Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                      Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                      In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                      The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                      Challenges in looking for and creating innovation when teams are distributed.
                                                                      Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                      I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                      Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                      The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                      Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                      What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                      In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                      The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                      Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                      This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                      Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                      Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                      After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                      This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                      Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                        \n
                                                                      1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                      2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                        Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                        She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                        She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                        You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                        \n\n\n\n

                                                                        Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                        While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                        Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                        1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                        2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                        3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                        These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                        Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                        She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                        What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                        Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                        In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                        The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                        Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                        (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                        In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                        A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                        Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                        Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                        Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                        Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                        \"\"<\/a><\/figure>\n\n\n\n

                                                                        Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                        If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                        As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                        This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                        As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                        As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                        \n

                                                                        In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                        We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                        1. Build your persona well
                                                                        Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                        2. Focus on framing the problem
                                                                        Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                        3. Generate multiple options for the same problem
                                                                        Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                        This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                        Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                        Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                        The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                        In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                        How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                        When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                        The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                        An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                        \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                        Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                        Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                        Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                        Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                        In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                        The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                        Challenges in looking for and creating innovation when teams are distributed.
                                                                        Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                        I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                        Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                        The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                        Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                        What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                        In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                        The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                        Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                        This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                        Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                        Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                        After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                        This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                        Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                          \n
                                                                        1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                        2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                          Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                          She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                          She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                          You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                          \n\n\n\n

                                                                          Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                          While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                          Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                          1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                          2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                          3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                          These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                          Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                          She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                          What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                          Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                          In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                          The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                          Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                          (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                          In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                          A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                          Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                          Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                          Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                          Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                          \"\"<\/a><\/figure>\n\n\n\n

                                                                          Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                          If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                          As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                          This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                          As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                          As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                          \n

                                                                          My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                          In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                          We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                          1. Build your persona well
                                                                          Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                          2. Focus on framing the problem
                                                                          Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                          3. Generate multiple options for the same problem
                                                                          Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                          This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                          Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                          Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                          The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                          In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                          How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                          When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                          The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                          An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                          \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                          Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                          Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                          Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                          Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                          In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                          The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                          Challenges in looking for and creating innovation when teams are distributed.
                                                                          Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                          I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                          Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                          The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                          Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                          What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                          In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                          The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                          Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                          This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                          Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                          Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                          After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                          This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                          Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                            \n
                                                                          1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                          2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                            Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                            She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                            She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                            You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                            \n\n\n\n

                                                                            Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                            While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                            Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                            1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                            2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                            3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                            These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                            Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                            She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                            What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                            Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                            In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                            The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                            Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                            (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                            In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                            A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                            Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                            Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                            Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                            Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                            \"\"<\/a><\/figure>\n\n\n\n

                                                                            Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                            If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                            As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                            This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                            As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                            As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                            \n

                                                                            Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                            My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                            In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                            We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                            1. Build your persona well
                                                                            Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                            2. Focus on framing the problem
                                                                            Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                            3. Generate multiple options for the same problem
                                                                            Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                            This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                            Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                            Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                            The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                            In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                            How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                            When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                            The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                            An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                            \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                            Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                            Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                            Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                            Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                            In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                            The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                            Challenges in looking for and creating innovation when teams are distributed.
                                                                            Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                            I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                            Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                            The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                            Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                            What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                            In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                            The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                            Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                            This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                            Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                            Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                            After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                            This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                            Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                              \n
                                                                            1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                            2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                              Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                              She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                              She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                              You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                              \n\n\n\n

                                                                              Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                              While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                              Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                              1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                              2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                              3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                              These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                              Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                              She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                              What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                              Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                              In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                              The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                              Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                              (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                              In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                              A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                              Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                              Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                              Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                              Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                              \"\"<\/a><\/figure>\n\n\n\n

                                                                              Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                              If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                              As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                              This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                              As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                              As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                              \n

                                                                              A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                              Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                              My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                              In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                              We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                              1. Build your persona well
                                                                              Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                              2. Focus on framing the problem
                                                                              Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                              3. Generate multiple options for the same problem
                                                                              Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                              This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                              Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                              Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                              The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                              In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                              How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                              When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                              The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                              An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                              \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                              Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                              Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                              Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                              Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                              In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                              The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                              Challenges in looking for and creating innovation when teams are distributed.
                                                                              Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                              I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                              Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                              The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                              Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                              What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                              In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                              The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                              Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                              This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                              Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                              Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                              After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                              This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                              Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                \n
                                                                              1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                              2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                \n\n\n\n

                                                                                Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                \"\"<\/a><\/figure>\n\n\n\n

                                                                                Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                \n

                                                                                However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                1. Build your persona well
                                                                                Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                2. Focus on framing the problem
                                                                                Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                3. Generate multiple options for the same problem
                                                                                Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                Challenges in looking for and creating innovation when teams are distributed.
                                                                                Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                  \n
                                                                                1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                  Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                  She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                  She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                  You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                  \n\n\n\n

                                                                                  Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                  While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                  Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                  1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                  2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                  3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                  These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                  Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                  She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                  What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                  Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                  In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                  The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                  Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                  (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                  In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                  A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                  Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                  Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                  Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                  Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                  \"\"<\/a><\/figure>\n\n\n\n

                                                                                  Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                  If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                  As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                  This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                  As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                  As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                  \n

                                                                                  Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                  However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                  A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                  Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                  My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                  In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                  We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                  1. Build your persona well
                                                                                  Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                  2. Focus on framing the problem
                                                                                  Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                  3. Generate multiple options for the same problem
                                                                                  Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                  This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                  Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                  Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                  The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                  In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                  How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                  When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                  The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                  An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                  \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                  Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                  Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                  Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                  Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                  In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                  The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                  Challenges in looking for and creating innovation when teams are distributed.
                                                                                  Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                  I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                  Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                  The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                  Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                  What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                  In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                  The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                  Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                  This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                  Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                  Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                  After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                  This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                  Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                    \n
                                                                                  1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                  2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                    Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                    She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                    She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                    You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                    \n\n\n\n

                                                                                    Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                    While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                    Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                    1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                    2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                    3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                    These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                    Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                    She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                    What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                    Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                    In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                    The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                    Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                    (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                    In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                    A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                    Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                    Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                    Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                    Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                    \"\"<\/a><\/figure>\n\n\n\n

                                                                                    Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                    If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                    As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                    This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                    As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                    As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                    \n

                                                                                    Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                    Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                    However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                    A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                    Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                    My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                    In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                    We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                    1. Build your persona well
                                                                                    Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                    2. Focus on framing the problem
                                                                                    Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                    3. Generate multiple options for the same problem
                                                                                    Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                    This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                    Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                    Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                    The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                    In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                    How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                    When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                    The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                    An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                    \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                    Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                    Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                    Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                    Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                    In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                    The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                    Challenges in looking for and creating innovation when teams are distributed.
                                                                                    Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                    I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                    Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                    The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                    Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                    What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                    In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                    The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                    Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                    This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                    Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                    Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                    After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                    This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                    Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                      \n
                                                                                    1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                    2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                      Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                      She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                      She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                      You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                      \n\n\n\n

                                                                                      Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                      While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                      Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                      1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                      2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                      3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                      These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                      Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                      She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                      What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                      Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                      In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                      The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                      Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                      (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                      In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                      A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                      Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                      Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                      Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                      Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                      \"\"<\/a><\/figure>\n\n\n\n

                                                                                      Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                      If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                      As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                      This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                      As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                      As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                      \n

                                                                                      Remember,<\/p>\n\n\n\n

                                                                                      Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                      Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                      However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                      A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                      Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                      My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                      In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                      We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                      1. Build your persona well
                                                                                      Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                      2. Focus on framing the problem
                                                                                      Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                      3. Generate multiple options for the same problem
                                                                                      Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                      This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                      Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                      Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                      The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                      In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                      How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                      When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                      The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                      An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                      \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                      Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                      Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                      Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                      Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                      In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                      The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                      Challenges in looking for and creating innovation when teams are distributed.
                                                                                      Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                      I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                      Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                      The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                      Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                      What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                      In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                      The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                      Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                      This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                      Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                      Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                      After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                      This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                      Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                        \n
                                                                                      1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                      2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                        Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                        She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                        She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                        You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                        \n\n\n\n

                                                                                        Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                        While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                        Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                        1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                        2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                        3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                        These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                        Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                        She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                        What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                        Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                        In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                        The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                        Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                        (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                        In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                        A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                        Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                        Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                        Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                        Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                        \"\"<\/a><\/figure>\n\n\n\n

                                                                                        Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                        If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                        As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                        This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                        As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                        As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                        \n

                                                                                        Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                        Remember,<\/p>\n\n\n\n

                                                                                        Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                        Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                        However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                        A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                        Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                        My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                        In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                        We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                        1. Build your persona well
                                                                                        Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                        2. Focus on framing the problem
                                                                                        Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                        3. Generate multiple options for the same problem
                                                                                        Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                        This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                        Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                        Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                        The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                        In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                        How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                        When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                        The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                        An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                        \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                        Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                        Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                        Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                        Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                        In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                        The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                        Challenges in looking for and creating innovation when teams are distributed.
                                                                                        Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                        I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                        Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                        The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                        Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                        What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                        In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                        The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                        Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                        This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                        Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                        Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                        After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                        This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                        Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                          \n
                                                                                        1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                        2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                          Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                          She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                          She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                          You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                          \n\n\n\n

                                                                                          Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                          While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                          Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                          1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                          2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                          3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                          These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                          Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                          She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                          What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                          Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                          In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                          The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                          Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                          (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                          In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                          A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                          Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                          Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                          Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                          Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                          \"\"<\/a><\/figure>\n\n\n\n

                                                                                          Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                          If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                          As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                          This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                          As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                          As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                          \n

                                                                                          In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                          Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                          Remember,<\/p>\n\n\n\n

                                                                                          Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                          Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                          However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                          A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                          Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                          My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                          In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                          We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                          1. Build your persona well
                                                                                          Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                          2. Focus on framing the problem
                                                                                          Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                          3. Generate multiple options for the same problem
                                                                                          Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                          This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                          Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                          Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                          The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                          In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                          How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                          When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                          The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                          An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                          \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                          Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                          Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                          Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                          Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                          In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                          The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                          Challenges in looking for and creating innovation when teams are distributed.
                                                                                          Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                          I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                          Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                          The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                          Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                          What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                          In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                          The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                          Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                          This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                          Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                          Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                          After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                          This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                          Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                            \n
                                                                                          1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                          2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                            Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                            She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                            She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                            You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                            \n\n\n\n

                                                                                            Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                            While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                            Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                            1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                            2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                            3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                            These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                            Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                            She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                            What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                            Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                            In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                            The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                            Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                            (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                            In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                            A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                            Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                            Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                            Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                            Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                            \"\"<\/a><\/figure>\n\n\n\n

                                                                                            Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                            If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                            As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                            This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                            As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                            As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                            \n

                                                                                            Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                            In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                            Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                            Remember,<\/p>\n\n\n\n

                                                                                            Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                            Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                            However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                            A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                            Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                            My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                            In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                            We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                            1. Build your persona well
                                                                                            Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                            2. Focus on framing the problem
                                                                                            Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                            3. Generate multiple options for the same problem
                                                                                            Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                            This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                            Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                            Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                            The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                            In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                            How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                            When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                            The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                            An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                            \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                            Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                            Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                            Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                            Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                            In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                            The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                            Challenges in looking for and creating innovation when teams are distributed.
                                                                                            Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                            I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                            Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                            The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                            Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                            What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                            In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                            The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                            Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                            This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                            Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                            Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                            After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                            This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                            Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                              \n
                                                                                            1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                            2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                              Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                              She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                              She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                              You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                              \n\n\n\n

                                                                                              Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                              While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                              Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                              1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                              2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                              3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                              These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                              Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                              She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                              What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                              Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                              In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                              The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                              Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                              (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                              In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                              A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                              Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                              Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                              Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                              Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                              \"\"<\/a><\/figure>\n\n\n\n

                                                                                              Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                              If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                              As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                              This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                              As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                              As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                              \n

                                                                                              Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                              Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                              In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                              Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                              Remember,<\/p>\n\n\n\n

                                                                                              Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                              Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                              However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                              A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                              Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                              My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                              In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                              We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                              1. Build your persona well
                                                                                              Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                              2. Focus on framing the problem
                                                                                              Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                              3. Generate multiple options for the same problem
                                                                                              Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                              This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                              Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                              Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                              The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                              In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                              How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                              When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                              The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                              An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                              \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                              Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                              Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                              Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                              Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                              In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                              The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                              Challenges in looking for and creating innovation when teams are distributed.
                                                                                              Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                              I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                              Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                              The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                              Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                              What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                              In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                              The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                              Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                              This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                              Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                              Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                              After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                              This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                              Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                \n
                                                                                              1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                              2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                \n\n\n\n

                                                                                                Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                \"\"<\/a><\/figure>\n\n\n\n

                                                                                                Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                \n

                                                                                                3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                Remember,<\/p>\n\n\n\n

                                                                                                Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                1. Build your persona well
                                                                                                Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                2. Focus on framing the problem
                                                                                                Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                3. Generate multiple options for the same problem
                                                                                                Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                Challenges in looking for and creating innovation when teams are distributed.
                                                                                                Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                  \n
                                                                                                1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                  Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                  She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                  She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                  You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                  \n\n\n\n

                                                                                                  Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                  While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                  Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                  1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                  2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                  3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                  These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                  Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                  She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                  What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                  Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                  In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                  The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                  Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                  (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                  In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                  A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                  Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                  Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                  Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                  Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                  \"\"<\/a><\/figure>\n\n\n\n

                                                                                                  Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                  If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                  As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                  This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                  As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                  As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                  \n

                                                                                                  Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                  3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                  Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                  Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                  In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                  Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                  Remember,<\/p>\n\n\n\n

                                                                                                  Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                  Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                  However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                  A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                  Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                  My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                  In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                  We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                  1. Build your persona well
                                                                                                  Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                  2. Focus on framing the problem
                                                                                                  Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                  3. Generate multiple options for the same problem
                                                                                                  Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                  This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                  Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                  Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                  The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                  In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                  How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                  When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                  The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                  An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                  \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                  Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                  Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                  Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                  Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                  In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                  The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                  Challenges in looking for and creating innovation when teams are distributed.
                                                                                                  Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                  I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                  Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                  The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                  Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                  What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                  In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                  The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                  Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                  This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                  Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                  Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                  After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                  This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                  Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                    \n
                                                                                                  1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                  2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                    Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                    She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                    She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                    You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                    \n\n\n\n

                                                                                                    Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                    While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                    Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                    1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                    2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                    3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                    These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                    Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                    She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                    What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                    Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                    In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                    The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                    Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                    (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                    In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                    A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                    Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                    Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                    Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                    Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                    \"\"<\/a><\/figure>\n\n\n\n

                                                                                                    Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                    If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                    As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                    This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                    As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                    As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                    \n

                                                                                                    Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                    Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                    3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                    Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                    Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                    In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                    Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                    Remember,<\/p>\n\n\n\n

                                                                                                    Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                    Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                    However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                    A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                    Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                    My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                    In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                    We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                    1. Build your persona well
                                                                                                    Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                    2. Focus on framing the problem
                                                                                                    Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                    3. Generate multiple options for the same problem
                                                                                                    Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                    This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                    Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                    Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                    The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                    In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                    How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                    When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                    The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                    An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                    \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                    Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                    Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                    Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                    Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                    In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                    The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                    Challenges in looking for and creating innovation when teams are distributed.
                                                                                                    Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                    I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                    Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                    The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                    Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                    What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                    In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                    The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                    Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                    This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                    Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                    Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                    After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                    This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                    Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                      \n
                                                                                                    1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                    2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                      Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                      She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                      She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                      You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                      \n\n\n\n

                                                                                                      Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                      While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                      Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                      1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                      2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                      3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                      These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                      Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                      She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                      What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                      Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                      In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                      The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                      Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                      (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                      In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                      A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                      Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                      Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                      Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                      Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                      \"\"<\/a><\/figure>\n\n\n\n

                                                                                                      Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                      If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                      As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                      This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                      As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                      As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                      \n

                                                                                                      Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.<\/p>\n\n\n\n

                                                                                                      Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                      Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                      3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                      Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                      Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                      In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                      Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                      Remember,<\/p>\n\n\n\n

                                                                                                      Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                      Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                      However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                      A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                      Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                      My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                      In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                      We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                      1. Build your persona well
                                                                                                      Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                      2. Focus on framing the problem
                                                                                                      Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                      3. Generate multiple options for the same problem
                                                                                                      Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                      This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                      Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                      Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                      The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                      In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                      How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                      When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                      The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                      An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                      \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                      Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                      Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                      Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                      Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                      In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                      The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                      Challenges in looking for and creating innovation when teams are distributed.
                                                                                                      Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                      I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                      Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                      The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                      Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                      What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                      In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                      The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                      Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                      This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                      Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                      Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                      After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                      This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                      Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                        \n
                                                                                                      1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                      2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                        Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                        She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                        She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                        You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                        \n\n\n\n

                                                                                                        Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                        While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                        Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                        1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                        2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                        3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                        These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                        Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                        She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                        What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                        Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                        In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                        The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                        Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                        (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                        In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                        A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                        Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                        Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                        Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                        Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                        \"\"<\/a><\/figure>\n\n\n\n

                                                                                                        Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                        If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                        As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                        This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                        As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                        As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                        \n

                                                                                                        2. Keep your planning appropriately light:<\/strong><\/p>\n\n\n\n

                                                                                                        Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.<\/p>\n\n\n\n

                                                                                                        Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                        Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                        3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                        Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                        Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                        In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                        Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                        Remember,<\/p>\n\n\n\n

                                                                                                        Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                        Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                        However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                        A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                        Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                        My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                        In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                        We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                        1. Build your persona well
                                                                                                        Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                        2. Focus on framing the problem
                                                                                                        Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                        3. Generate multiple options for the same problem
                                                                                                        Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                        This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                        Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                        Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                        The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                        In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                        How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                        When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                        The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                        An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                        \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                        Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                        Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                        Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                        Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                        In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                        The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                        Challenges in looking for and creating innovation when teams are distributed.
                                                                                                        Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                        I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                        Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                        The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                        Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                        What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                        In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                        The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                        Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                        This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                        Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                        Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                        After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                        This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                        Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                          \n
                                                                                                        1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                        2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                          Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                          She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                          She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                          You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                          \n\n\n\n

                                                                                                          Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                          While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                          Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                          1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                          2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                          3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                          These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                          Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                          She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                          What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                          Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                          In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                          The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                          Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                          (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                          In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                          A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                          Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                          Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                          Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                          Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                          \"\"<\/a><\/figure>\n\n\n\n

                                                                                                          Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                          If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                          As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                          This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                          As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                          As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                          \n

                                                                                                          Sprint planning, then, can identify tasks that need to be done in the sprint to provide that value to users. The value could be stabilizing a feature that has lots of bugs, or developing a functionality that users will like providing feedback on. Without an overall goal for the sprint - the sprint planning process will start weaker.<\/p>\n\n\n\n

                                                                                                          2. Keep your planning appropriately light:<\/strong><\/p>\n\n\n\n

                                                                                                          Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.<\/p>\n\n\n\n

                                                                                                          Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                          Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                          3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                          Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                          Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                          In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                          Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                          Remember,<\/p>\n\n\n\n

                                                                                                          Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                          Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                          However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                          A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                          Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                          My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                          In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                          We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                          1. Build your persona well
                                                                                                          Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                          2. Focus on framing the problem
                                                                                                          Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                          3. Generate multiple options for the same problem
                                                                                                          Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                          This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                          Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                          Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                          The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                          In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                          How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                          When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                          The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                          An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                          \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                          Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                          Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                          Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                          Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                          In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                          The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                          Challenges in looking for and creating innovation when teams are distributed.
                                                                                                          Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                          I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                          Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                          The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                          Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                          What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                          In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                          The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                          Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                          This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                          Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                          Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                          After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                          This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                          Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                            \n
                                                                                                          1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                          2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                            Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                            She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                            She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                            You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                            \n\n\n\n

                                                                                                            Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                            While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                            Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                            1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                            2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                            3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                            These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                            Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                            She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                            What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                            Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                            In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                            The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                            Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                            (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                            In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                            A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                            Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                            Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                            Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                            Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                            \"\"<\/a><\/figure>\n\n\n\n

                                                                                                            Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                            If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                            As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                            This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                            As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                            As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                            \n

                                                                                                            The purpose of sprint planning must be re-focused to identify the value provided to the user at the end of a sprint.<\/p>\n\n\n\n

                                                                                                            Sprint planning, then, can identify tasks that need to be done in the sprint to provide that value to users. The value could be stabilizing a feature that has lots of bugs, or developing a functionality that users will like providing feedback on. Without an overall goal for the sprint - the sprint planning process will start weaker.<\/p>\n\n\n\n

                                                                                                            2. Keep your planning appropriately light:<\/strong><\/p>\n\n\n\n

                                                                                                            Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.<\/p>\n\n\n\n

                                                                                                            Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                            Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                            3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                            Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                            Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                            In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                            Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                            Remember,<\/p>\n\n\n\n

                                                                                                            Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                            Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                            However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                            A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                            Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                            My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                            In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                            We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                            1. Build your persona well
                                                                                                            Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                            2. Focus on framing the problem
                                                                                                            Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                            3. Generate multiple options for the same problem
                                                                                                            Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                            This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                            Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                            Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                            The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                            In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                            How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                            When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                            The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                            An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                            \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                            Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                            Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                            Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                            Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                            In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                            The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                            Challenges in looking for and creating innovation when teams are distributed.
                                                                                                            Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                            I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                            Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                            The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                            Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                            What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                            In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                            The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                            Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                            This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                            Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                            Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                            After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                            This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                            Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                              \n
                                                                                                            1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                            2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                              Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                              She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                              She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                              You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                              \n\n\n\n

                                                                                                              Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                              While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                              Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                              1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                              2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                              3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                              These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                              Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                              She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                              What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                              Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                              In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                              The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                              Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                              (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                              In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                              A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                              Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                              Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                              Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                              Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                              \"\"<\/a><\/figure>\n\n\n\n

                                                                                                              Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                              If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                              As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                              This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                              As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                              As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                              \n

                                                                                                              1. Focus on a key goal for the sprint:<\/strong><\/p>\n\n\n\n

                                                                                                              The purpose of sprint planning must be re-focused to identify the value provided to the user at the end of a sprint.<\/p>\n\n\n\n

                                                                                                              Sprint planning, then, can identify tasks that need to be done in the sprint to provide that value to users. The value could be stabilizing a feature that has lots of bugs, or developing a functionality that users will like providing feedback on. Without an overall goal for the sprint - the sprint planning process will start weaker.<\/p>\n\n\n\n

                                                                                                              2. Keep your planning appropriately light:<\/strong><\/p>\n\n\n\n

                                                                                                              Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.<\/p>\n\n\n\n

                                                                                                              Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                              Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                              3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                              Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                              Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                              In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                              Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                              Remember,<\/p>\n\n\n\n

                                                                                                              Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                              Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                              However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                              A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                              Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                              My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                              In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                              We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                              1. Build your persona well
                                                                                                              Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                              2. Focus on framing the problem
                                                                                                              Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                              3. Generate multiple options for the same problem
                                                                                                              Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                              This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                              Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                              Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                              The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                              In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                              How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                              When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                              The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                              An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                              \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                              Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                              Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                              Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                              Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                              In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                              The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                              Challenges in looking for and creating innovation when teams are distributed.
                                                                                                              Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                              I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                              Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                              The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                              Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                              What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                              In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                              The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                              Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                              This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                              Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                              Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                              After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                              This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                              Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                                \n
                                                                                                              1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                              2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                                Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                                She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                                She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                                You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                                \n\n\n\n

                                                                                                                Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                                Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                                1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                                2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                                3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                                These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                                Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                                She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                                What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                                In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                                The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                                Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                                (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                                In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                                A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                                Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                                Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                                Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                                Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                                \"\"<\/a><\/figure>\n\n\n\n

                                                                                                                Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                                If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                                As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                                This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                                As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                                As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                                \n

                                                                                                                If you are looking for ways to re-boot your planning, consider the below<\/p>\n\n\n\n

                                                                                                                1. Focus on a key goal for the sprint:<\/strong><\/p>\n\n\n\n

                                                                                                                The purpose of sprint planning must be re-focused to identify the value provided to the user at the end of a sprint.<\/p>\n\n\n\n

                                                                                                                Sprint planning, then, can identify tasks that need to be done in the sprint to provide that value to users. The value could be stabilizing a feature that has lots of bugs, or developing a functionality that users will like providing feedback on. Without an overall goal for the sprint - the sprint planning process will start weaker.<\/p>\n\n\n\n

                                                                                                                2. Keep your planning appropriately light:<\/strong><\/p>\n\n\n\n

                                                                                                                Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.<\/p>\n\n\n\n

                                                                                                                Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                                Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                                3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                                Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                                Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                                In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                                Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                                Remember,<\/p>\n\n\n\n

                                                                                                                Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                                Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                                However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                                A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                                Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                                My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                                In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                                We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                                1. Build your persona well
                                                                                                                Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                                2. Focus on framing the problem
                                                                                                                Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                                3. Generate multiple options for the same problem
                                                                                                                Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                                This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                                Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                                Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                                The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                                In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                                How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                                The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                                An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                                \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                                Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                                Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                                Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                                Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                                In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                                The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                                Challenges in looking for and creating innovation when teams are distributed.
                                                                                                                Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                                I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                                Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                                The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                                Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                                What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                                In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                                The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                                Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                                This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                                Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                                Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                                After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                                This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                                Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                                  \n
                                                                                                                1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                                2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                                  Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                                  She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                                  She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                                  You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                                  \n\n\n\n

                                                                                                                  Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                  While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                                  Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                                  1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                                  2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                                  3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                                  These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                                  Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                                  She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                                  What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                  Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                                  In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                                  The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                                  Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                                  (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                                  In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                                  A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                                  Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                                  Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                                  Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                                  Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                                  \"\"<\/a><\/figure>\n\n\n\n

                                                                                                                  Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                                  If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                                  As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                                  This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                                  As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                                  As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                                  \n

                                                                                                                  1. Why plan for the sprint?
                                                                                                                  2. What do the teams expect to do with the sprint plan?
                                                                                                                  3. And, Why 'estimate' the stories?<\/p>\n\n\n\n

                                                                                                                  If you are looking for ways to re-boot your planning, consider the below<\/p>\n\n\n\n

                                                                                                                  1. Focus on a key goal for the sprint:<\/strong><\/p>\n\n\n\n

                                                                                                                  The purpose of sprint planning must be re-focused to identify the value provided to the user at the end of a sprint.<\/p>\n\n\n\n

                                                                                                                  Sprint planning, then, can identify tasks that need to be done in the sprint to provide that value to users. The value could be stabilizing a feature that has lots of bugs, or developing a functionality that users will like providing feedback on. Without an overall goal for the sprint - the sprint planning process will start weaker.<\/p>\n\n\n\n

                                                                                                                  2. Keep your planning appropriately light:<\/strong><\/p>\n\n\n\n

                                                                                                                  Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.<\/p>\n\n\n\n

                                                                                                                  Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                                  Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                                  3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                                  Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                                  Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                                  In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                                  Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                                  Remember,<\/p>\n\n\n\n

                                                                                                                  Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                                  Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                                  However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                                  A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                                  Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                                  My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                                  In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                                  We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                                  1. Build your persona well
                                                                                                                  Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                                  2. Focus on framing the problem
                                                                                                                  Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                                  3. Generate multiple options for the same problem
                                                                                                                  Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                                  This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                                  Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                                  Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                                  The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                                  In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                                  How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                  When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                                  The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                                  An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                                  \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                                  Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                                  Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                                  Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                                  Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                                  In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                                  The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                                  Challenges in looking for and creating innovation when teams are distributed.
                                                                                                                  Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                                  I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                                  Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                                  The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                                  Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                                  What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                                  In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                                  The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                                  Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                                  This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                                  Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                                  Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                                  After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                                  This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                                  Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                                    \n
                                                                                                                  1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                                  2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                                    Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                                    She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                                    She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                                    You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                                    \n\n\n\n

                                                                                                                    Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                    While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                                    Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                                    1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                                    2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                                    3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                                    These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                                    Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                                    She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                                    What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                    Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                                    In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                                    The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                                    Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                                    (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                                    In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                                    A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                                    Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                                    Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                                    Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                                    Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                                    \"\"<\/a><\/figure>\n\n\n\n

                                                                                                                    Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                                    If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                                    As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                                    This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                                    As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                                    As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                                    \n

                                                                                                                    Many teams that follow the above routine (or its minor variations) have been exposed to some form of Agile practices. Teams that do this, feel they are just following a routine and struggle to answer the following questions:<\/p>\n\n\n\n

                                                                                                                    1. Why plan for the sprint?
                                                                                                                    2. What do the teams expect to do with the sprint plan?
                                                                                                                    3. And, Why 'estimate' the stories?<\/p>\n\n\n\n

                                                                                                                    If you are looking for ways to re-boot your planning, consider the below<\/p>\n\n\n\n

                                                                                                                    1. Focus on a key goal for the sprint:<\/strong><\/p>\n\n\n\n

                                                                                                                    The purpose of sprint planning must be re-focused to identify the value provided to the user at the end of a sprint.<\/p>\n\n\n\n

                                                                                                                    Sprint planning, then, can identify tasks that need to be done in the sprint to provide that value to users. The value could be stabilizing a feature that has lots of bugs, or developing a functionality that users will like providing feedback on. Without an overall goal for the sprint - the sprint planning process will start weaker.<\/p>\n\n\n\n

                                                                                                                    2. Keep your planning appropriately light:<\/strong><\/p>\n\n\n\n

                                                                                                                    Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.<\/p>\n\n\n\n

                                                                                                                    Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                                    Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                                    3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                                    Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                                    Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                                    In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                                    Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                                    Remember,<\/p>\n\n\n\n

                                                                                                                    Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                                    Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                                    However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                                    A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                                    Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                                    My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                                    In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                                    We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                                    1. Build your persona well
                                                                                                                    Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                                    2. Focus on framing the problem
                                                                                                                    Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                                    3. Generate multiple options for the same problem
                                                                                                                    Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                                    This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                                    Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                                    Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                                    The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                                    In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                                    How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                    When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                                    The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                                    An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                                    \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                                    Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                                    Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                                    Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                                    Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                                    In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                                    The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                                    Challenges in looking for and creating innovation when teams are distributed.
                                                                                                                    Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                                    I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                                    Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                                    The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                                    Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                                    What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                                    In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                                    The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                                    Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                                    This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                                    Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                                    Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                                    After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                                    This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                                    Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                                      \n
                                                                                                                    1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                                    2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                                      Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                                      She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                                      She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                                      You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                                      \n\n\n\n

                                                                                                                      Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                      While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                                      Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                                      1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                                      2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                                      3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                                      These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                                      Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                                      She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                                      What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                      Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                                      In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                                      The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                                      Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                                      (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                                      In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                                      A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                                      Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                                      Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                                      Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                                      Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                                      \"\"<\/a><\/figure>\n\n\n\n

                                                                                                                      Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                                      If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                                      As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                                      This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                                      As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                                      As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                                      \n

                                                                                                                      1. There are a set of stories (mostly) ready for an upcoming sprint.
                                                                                                                      2. Hence, the teams estimate their stories to pick a few stories from the backlog
                                                                                                                      3. The team uses story points - adopting Fibonacci series (I have not come across anything else!)
                                                                                                                      4. They may play planning poker, or, someone from the team proposes a number.
                                                                                                                      5. The team estimates stories and then pick stories until their velocity is reached.
                                                                                                                      6. Their velocity is the number that they have completed - could range from just completing development to some stories actually seen by users. For new teams, velocity is a number that the team may find reasonably impressive enough to tell outside.<\/p>\n\n\n\n

                                                                                                                      Many teams that follow the above routine (or its minor variations) have been exposed to some form of Agile practices. Teams that do this, feel they are just following a routine and struggle to answer the following questions:<\/p>\n\n\n\n

                                                                                                                      1. Why plan for the sprint?
                                                                                                                      2. What do the teams expect to do with the sprint plan?
                                                                                                                      3. And, Why 'estimate' the stories?<\/p>\n\n\n\n

                                                                                                                      If you are looking for ways to re-boot your planning, consider the below<\/p>\n\n\n\n

                                                                                                                      1. Focus on a key goal for the sprint:<\/strong><\/p>\n\n\n\n

                                                                                                                      The purpose of sprint planning must be re-focused to identify the value provided to the user at the end of a sprint.<\/p>\n\n\n\n

                                                                                                                      Sprint planning, then, can identify tasks that need to be done in the sprint to provide that value to users. The value could be stabilizing a feature that has lots of bugs, or developing a functionality that users will like providing feedback on. Without an overall goal for the sprint - the sprint planning process will start weaker.<\/p>\n\n\n\n

                                                                                                                      2. Keep your planning appropriately light:<\/strong><\/p>\n\n\n\n

                                                                                                                      Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.<\/p>\n\n\n\n

                                                                                                                      Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                                      Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                                      3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                                      Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                                      Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                                      In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                                      Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                                      Remember,<\/p>\n\n\n\n

                                                                                                                      Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                                      Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                                      However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                                      A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                                      Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                                      My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                                      In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                                      We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                                      1. Build your persona well
                                                                                                                      Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                                      2. Focus on framing the problem
                                                                                                                      Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                                      3. Generate multiple options for the same problem
                                                                                                                      Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                                      This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                                      Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                                      Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                                      The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                                      In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                                      How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                      When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                                      The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                                      An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                                      \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                                      Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                                      Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                                      Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                                      Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                                      In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                                      The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                                      Challenges in looking for and creating innovation when teams are distributed.
                                                                                                                      Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                                      I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                                      Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                                      The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                                      Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                                      What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                                      In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                                      The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                                      Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                                      This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                                      Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                                      Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                                      After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                                      This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                                      Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                                        \n
                                                                                                                      1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                                      2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                                        Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                                        She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                                        She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                                        You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                                        \n\n\n\n

                                                                                                                        Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                        While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                                        Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                                        1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                                        2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                                        3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                                        These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                                        Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                                        She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                                        What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                        Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                                        In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                                        The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                                        Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                                        (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                                        In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                                        A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                                        Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                                        Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                                        Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                                        Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                                        \"\"<\/a><\/figure>\n\n\n\n

                                                                                                                        Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                                        If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                                        As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                                        This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                                        As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                                        As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                                        \n

                                                                                                                        Often, teams do their sprint planning in the following way:<\/p>\n\n\n\n

                                                                                                                        1. There are a set of stories (mostly) ready for an upcoming sprint.
                                                                                                                        2. Hence, the teams estimate their stories to pick a few stories from the backlog
                                                                                                                        3. The team uses story points - adopting Fibonacci series (I have not come across anything else!)
                                                                                                                        4. They may play planning poker, or, someone from the team proposes a number.
                                                                                                                        5. The team estimates stories and then pick stories until their velocity is reached.
                                                                                                                        6. Their velocity is the number that they have completed - could range from just completing development to some stories actually seen by users. For new teams, velocity is a number that the team may find reasonably impressive enough to tell outside.<\/p>\n\n\n\n

                                                                                                                        Many teams that follow the above routine (or its minor variations) have been exposed to some form of Agile practices. Teams that do this, feel they are just following a routine and struggle to answer the following questions:<\/p>\n\n\n\n

                                                                                                                        1. Why plan for the sprint?
                                                                                                                        2. What do the teams expect to do with the sprint plan?
                                                                                                                        3. And, Why 'estimate' the stories?<\/p>\n\n\n\n

                                                                                                                        If you are looking for ways to re-boot your planning, consider the below<\/p>\n\n\n\n

                                                                                                                        1. Focus on a key goal for the sprint:<\/strong><\/p>\n\n\n\n

                                                                                                                        The purpose of sprint planning must be re-focused to identify the value provided to the user at the end of a sprint.<\/p>\n\n\n\n

                                                                                                                        Sprint planning, then, can identify tasks that need to be done in the sprint to provide that value to users. The value could be stabilizing a feature that has lots of bugs, or developing a functionality that users will like providing feedback on. Without an overall goal for the sprint - the sprint planning process will start weaker.<\/p>\n\n\n\n

                                                                                                                        2. Keep your planning appropriately light:<\/strong><\/p>\n\n\n\n

                                                                                                                        Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.<\/p>\n\n\n\n

                                                                                                                        Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                                        Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                                        3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                                        Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                                        Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                                        In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                                        Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                                        Remember,<\/p>\n\n\n\n

                                                                                                                        Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                                        Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                                        However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                                        A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                                        Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                                        My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                                        In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                                        We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                                        1. Build your persona well
                                                                                                                        Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                                        2. Focus on framing the problem
                                                                                                                        Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                                        3. Generate multiple options for the same problem
                                                                                                                        Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                                        This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                                        Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                                        Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                                        The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                                        In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                                        How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                                        Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                        When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                                        The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                                        An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                                        \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                                        Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                                        Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                                        Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                                        Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                                        In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                                        The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                                        Challenges in looking for and creating innovation when teams are distributed.
                                                                                                                        Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                                        I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                                        Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                                        The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                                        Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                                        What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                                        In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                                        The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                                        Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                                        This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                                        Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                                        Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                                        After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                                        This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                                        Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                                          \n
                                                                                                                        1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                                        2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                                          Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                                          She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                                          She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                                          You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                                          \n\n\n\n

                                                                                                                          Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                          While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                                          Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                                          1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                                          2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                                          3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                                          These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                                          Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                                          She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                                          What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                          Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                                          In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                                          The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                                          Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                                          (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                                          In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                                          A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                                          Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                                          Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                                          Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                                          Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                                          \"\"<\/a><\/figure>\n\n\n\n

                                                                                                                          Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                                          If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                                          As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                                          This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                                          As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                                          As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                                          \n

                                                                                                                          This blog is more to share an observation and get inputs from as many folks as possible on sprint planning:<\/p>\n\n\n\n

                                                                                                                          Often, teams do their sprint planning in the following way:<\/p>\n\n\n\n

                                                                                                                          1. There are a set of stories (mostly) ready for an upcoming sprint.
                                                                                                                          2. Hence, the teams estimate their stories to pick a few stories from the backlog
                                                                                                                          3. The team uses story points - adopting Fibonacci series (I have not come across anything else!)
                                                                                                                          4. They may play planning poker, or, someone from the team proposes a number.
                                                                                                                          5. The team estimates stories and then pick stories until their velocity is reached.
                                                                                                                          6. Their velocity is the number that they have completed - could range from just completing development to some stories actually seen by users. For new teams, velocity is a number that the team may find reasonably impressive enough to tell outside.<\/p>\n\n\n\n

                                                                                                                          Many teams that follow the above routine (or its minor variations) have been exposed to some form of Agile practices. Teams that do this, feel they are just following a routine and struggle to answer the following questions:<\/p>\n\n\n\n

                                                                                                                          1. Why plan for the sprint?
                                                                                                                          2. What do the teams expect to do with the sprint plan?
                                                                                                                          3. And, Why 'estimate' the stories?<\/p>\n\n\n\n

                                                                                                                          If you are looking for ways to re-boot your planning, consider the below<\/p>\n\n\n\n

                                                                                                                          1. Focus on a key goal for the sprint:<\/strong><\/p>\n\n\n\n

                                                                                                                          The purpose of sprint planning must be re-focused to identify the value provided to the user at the end of a sprint.<\/p>\n\n\n\n

                                                                                                                          Sprint planning, then, can identify tasks that need to be done in the sprint to provide that value to users. The value could be stabilizing a feature that has lots of bugs, or developing a functionality that users will like providing feedback on. Without an overall goal for the sprint - the sprint planning process will start weaker.<\/p>\n\n\n\n

                                                                                                                          2. Keep your planning appropriately light:<\/strong><\/p>\n\n\n\n

                                                                                                                          Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.<\/p>\n\n\n\n

                                                                                                                          Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                                          Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                                          3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                                          Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                                          Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                                          In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                                          Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                                          Remember,<\/p>\n\n\n\n

                                                                                                                          Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                                          Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                                          However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                                          A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                                          Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                                          My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                                          In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                                          We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                                          1. Build your persona well
                                                                                                                          Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                                          2. Focus on framing the problem
                                                                                                                          Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                                          3. Generate multiple options for the same problem
                                                                                                                          Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                                          This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                                          Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                                          Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                                          The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                                          In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                                          How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                                          Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                          When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                                          The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                                          An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                                          \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                                          Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                                          Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                                          Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                                          Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                                          In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                                          The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                                          Challenges in looking for and creating innovation when teams are distributed.
                                                                                                                          Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                                          I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                                          Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                                          The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                                          Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                                          What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                                          In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                                          The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                                          Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                                          This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                                          Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                                          Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                                          After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                                          This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                                          Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                                            \n
                                                                                                                          1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                                          2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                                            Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                                            She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                                            She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                                            You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                                            \n\n\n\n

                                                                                                                            Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                            While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                                            Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                                            1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                                            2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                                            3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                                            These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                                            Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                                            She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                                            What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                            Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                                            In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                                            The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                                            Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                                            (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                                            In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                                            A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                                            Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                                            Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                                            Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                                            Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                                            \"\"<\/a><\/figure>\n\n\n\n

                                                                                                                            Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                                            If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                                            As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                                            This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                                            As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                                            As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                                            \n

                                                                                                                            What will you advise Ankit to do? How should he approach planning and what should he inform Linda and other stakeholders.<\/p>\n","post_title":"CHOW #96- A tricky Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-96-tricky-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:20:30","post_modified_gmt":"2024-01-25 11:20:30","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9971","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":9968,"post_author":"14","post_date":"2018-03-26 10:50:41","post_date_gmt":"2018-03-26 05:20:41","post_content":"\n

                                                                                                                            This blog is more to share an observation and get inputs from as many folks as possible on sprint planning:<\/p>\n\n\n\n

                                                                                                                            Often, teams do their sprint planning in the following way:<\/p>\n\n\n\n

                                                                                                                            1. There are a set of stories (mostly) ready for an upcoming sprint.
                                                                                                                            2. Hence, the teams estimate their stories to pick a few stories from the backlog
                                                                                                                            3. The team uses story points - adopting Fibonacci series (I have not come across anything else!)
                                                                                                                            4. They may play planning poker, or, someone from the team proposes a number.
                                                                                                                            5. The team estimates stories and then pick stories until their velocity is reached.
                                                                                                                            6. Their velocity is the number that they have completed - could range from just completing development to some stories actually seen by users. For new teams, velocity is a number that the team may find reasonably impressive enough to tell outside.<\/p>\n\n\n\n

                                                                                                                            Many teams that follow the above routine (or its minor variations) have been exposed to some form of Agile practices. Teams that do this, feel they are just following a routine and struggle to answer the following questions:<\/p>\n\n\n\n

                                                                                                                            1. Why plan for the sprint?
                                                                                                                            2. What do the teams expect to do with the sprint plan?
                                                                                                                            3. And, Why 'estimate' the stories?<\/p>\n\n\n\n

                                                                                                                            If you are looking for ways to re-boot your planning, consider the below<\/p>\n\n\n\n

                                                                                                                            1. Focus on a key goal for the sprint:<\/strong><\/p>\n\n\n\n

                                                                                                                            The purpose of sprint planning must be re-focused to identify the value provided to the user at the end of a sprint.<\/p>\n\n\n\n

                                                                                                                            Sprint planning, then, can identify tasks that need to be done in the sprint to provide that value to users. The value could be stabilizing a feature that has lots of bugs, or developing a functionality that users will like providing feedback on. Without an overall goal for the sprint - the sprint planning process will start weaker.<\/p>\n\n\n\n

                                                                                                                            2. Keep your planning appropriately light:<\/strong><\/p>\n\n\n\n

                                                                                                                            Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.<\/p>\n\n\n\n

                                                                                                                            Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                                            Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                                            3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                                            Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                                            Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                                            In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                                            Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                                            Remember,<\/p>\n\n\n\n

                                                                                                                            Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                                            Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                                            However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                                            A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                                            Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                                            My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                                            In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                                            We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                                            1. Build your persona well
                                                                                                                            Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                                            2. Focus on framing the problem
                                                                                                                            Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                                            3. Generate multiple options for the same problem
                                                                                                                            Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                                            This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                                            Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                                            Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                                            The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                                            In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                                            How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                                            Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                            When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                                            The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                                            An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                                            \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                                            Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                                            Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                                            Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                                            Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                                            In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                                            The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                                            Challenges in looking for and creating innovation when teams are distributed.
                                                                                                                            Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                                            I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                                            Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                                            The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                                            Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                                            What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                                            In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                                            The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                                            Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                                            This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                                            Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                                            Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                                            After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                                            This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                                            Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                                              \n
                                                                                                                            1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                                            2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                                              Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                                              She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                                              She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                                              You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                                              \n\n\n\n

                                                                                                                              Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                              While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                                              Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                                              1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                                              2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                                              3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                                              These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                                              Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                                              She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                                              What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                              Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                                              In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                                              The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                                              Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                                              (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                                              In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                                              A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                                              Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                                              Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                                              Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                                              Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                                              \"\"<\/a><\/figure>\n\n\n\n

                                                                                                                              Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                                              If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                                              As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                                              This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                                              As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                                              As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                                              \n

                                                                                                                              In the subsequent showcase, Linda asked Ankit when are they likely to deliver the feature. This question stumps Ankit. More worryingly, all the velocity numbers that looked great in earlier showcases seem to suggest they will complete the feature fast; whereas the team is not sure of many things.<\/p>\n\n\n\n

                                                                                                                              What will you advise Ankit to do? How should he approach planning and what should he inform Linda and other stakeholders.<\/p>\n","post_title":"CHOW #96- A tricky Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-96-tricky-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:20:30","post_modified_gmt":"2024-01-25 11:20:30","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9971","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":9968,"post_author":"14","post_date":"2018-03-26 10:50:41","post_date_gmt":"2018-03-26 05:20:41","post_content":"\n

                                                                                                                              This blog is more to share an observation and get inputs from as many folks as possible on sprint planning:<\/p>\n\n\n\n

                                                                                                                              Often, teams do their sprint planning in the following way:<\/p>\n\n\n\n

                                                                                                                              1. There are a set of stories (mostly) ready for an upcoming sprint.
                                                                                                                              2. Hence, the teams estimate their stories to pick a few stories from the backlog
                                                                                                                              3. The team uses story points - adopting Fibonacci series (I have not come across anything else!)
                                                                                                                              4. They may play planning poker, or, someone from the team proposes a number.
                                                                                                                              5. The team estimates stories and then pick stories until their velocity is reached.
                                                                                                                              6. Their velocity is the number that they have completed - could range from just completing development to some stories actually seen by users. For new teams, velocity is a number that the team may find reasonably impressive enough to tell outside.<\/p>\n\n\n\n

                                                                                                                              Many teams that follow the above routine (or its minor variations) have been exposed to some form of Agile practices. Teams that do this, feel they are just following a routine and struggle to answer the following questions:<\/p>\n\n\n\n

                                                                                                                              1. Why plan for the sprint?
                                                                                                                              2. What do the teams expect to do with the sprint plan?
                                                                                                                              3. And, Why 'estimate' the stories?<\/p>\n\n\n\n

                                                                                                                              If you are looking for ways to re-boot your planning, consider the below<\/p>\n\n\n\n

                                                                                                                              1. Focus on a key goal for the sprint:<\/strong><\/p>\n\n\n\n

                                                                                                                              The purpose of sprint planning must be re-focused to identify the value provided to the user at the end of a sprint.<\/p>\n\n\n\n

                                                                                                                              Sprint planning, then, can identify tasks that need to be done in the sprint to provide that value to users. The value could be stabilizing a feature that has lots of bugs, or developing a functionality that users will like providing feedback on. Without an overall goal for the sprint - the sprint planning process will start weaker.<\/p>\n\n\n\n

                                                                                                                              2. Keep your planning appropriately light:<\/strong><\/p>\n\n\n\n

                                                                                                                              Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.<\/p>\n\n\n\n

                                                                                                                              Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                                              Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                                              3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                                              Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                                              Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                                              In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                                              Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                                              Remember,<\/p>\n\n\n\n

                                                                                                                              Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                                              Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                                              However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                                              A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                                              Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                                              My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                                              In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                                              We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                                              1. Build your persona well
                                                                                                                              Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                                              2. Focus on framing the problem
                                                                                                                              Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                                              3. Generate multiple options for the same problem
                                                                                                                              Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                                              This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                                              Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                                              Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                                              The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                                              In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                                              How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                                              Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                              When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                                              The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                                              An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                                              \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                                              Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                                              Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                                              Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                                              Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                                              In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                                              The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                                              Challenges in looking for and creating innovation when teams are distributed.
                                                                                                                              Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                                              I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                                              Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                                              The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                                              Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                                              What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                                              In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                                              The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                                              Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                                              This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                                              Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                                              Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                                              After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                                              This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                                              Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                                                \n
                                                                                                                              1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                                              2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                                                Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                                                She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                                                She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                                                You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                                                \n\n\n\n

                                                                                                                                Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                                While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                                                Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                                                1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                                                2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                                                3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                                                These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                                                Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                                                She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                                                What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                                Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                                                In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                                                The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                                                Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                                                (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                                                In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                                                A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                                                Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                                                Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                                                Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                                                Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                                                \"\"<\/a><\/figure>\n\n\n\n

                                                                                                                                Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                                                If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                                                As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                                                This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                                                As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                                                As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                                                \n

                                                                                                                                Their business manager, Linda - a very senior person in product management informed them that the product will need a new feature. Their product owner walked them through the requirements, broke down into stories and also started their sprint<\/p>\n\n\n\n

                                                                                                                                In the subsequent showcase, Linda asked Ankit when are they likely to deliver the feature. This question stumps Ankit. More worryingly, all the velocity numbers that looked great in earlier showcases seem to suggest they will complete the feature fast; whereas the team is not sure of many things.<\/p>\n\n\n\n

                                                                                                                                What will you advise Ankit to do? How should he approach planning and what should he inform Linda and other stakeholders.<\/p>\n","post_title":"CHOW #96- A tricky Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-96-tricky-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:20:30","post_modified_gmt":"2024-01-25 11:20:30","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9971","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":9968,"post_author":"14","post_date":"2018-03-26 10:50:41","post_date_gmt":"2018-03-26 05:20:41","post_content":"\n

                                                                                                                                This blog is more to share an observation and get inputs from as many folks as possible on sprint planning:<\/p>\n\n\n\n

                                                                                                                                Often, teams do their sprint planning in the following way:<\/p>\n\n\n\n

                                                                                                                                1. There are a set of stories (mostly) ready for an upcoming sprint.
                                                                                                                                2. Hence, the teams estimate their stories to pick a few stories from the backlog
                                                                                                                                3. The team uses story points - adopting Fibonacci series (I have not come across anything else!)
                                                                                                                                4. They may play planning poker, or, someone from the team proposes a number.
                                                                                                                                5. The team estimates stories and then pick stories until their velocity is reached.
                                                                                                                                6. Their velocity is the number that they have completed - could range from just completing development to some stories actually seen by users. For new teams, velocity is a number that the team may find reasonably impressive enough to tell outside.<\/p>\n\n\n\n

                                                                                                                                Many teams that follow the above routine (or its minor variations) have been exposed to some form of Agile practices. Teams that do this, feel they are just following a routine and struggle to answer the following questions:<\/p>\n\n\n\n

                                                                                                                                1. Why plan for the sprint?
                                                                                                                                2. What do the teams expect to do with the sprint plan?
                                                                                                                                3. And, Why 'estimate' the stories?<\/p>\n\n\n\n

                                                                                                                                If you are looking for ways to re-boot your planning, consider the below<\/p>\n\n\n\n

                                                                                                                                1. Focus on a key goal for the sprint:<\/strong><\/p>\n\n\n\n

                                                                                                                                The purpose of sprint planning must be re-focused to identify the value provided to the user at the end of a sprint.<\/p>\n\n\n\n

                                                                                                                                Sprint planning, then, can identify tasks that need to be done in the sprint to provide that value to users. The value could be stabilizing a feature that has lots of bugs, or developing a functionality that users will like providing feedback on. Without an overall goal for the sprint - the sprint planning process will start weaker.<\/p>\n\n\n\n

                                                                                                                                2. Keep your planning appropriately light:<\/strong><\/p>\n\n\n\n

                                                                                                                                Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.<\/p>\n\n\n\n

                                                                                                                                Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                                                Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                                                3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                                                Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                                                Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                                                In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                                                Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                                                Remember,<\/p>\n\n\n\n

                                                                                                                                Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                                                Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                                                However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                                                A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                                                Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                                                My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                                                In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                                                We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                                                1. Build your persona well
                                                                                                                                Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                                                2. Focus on framing the problem
                                                                                                                                Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                                                3. Generate multiple options for the same problem
                                                                                                                                Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                                                This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                                                Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                                                Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                                                The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                                                In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                                                How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                                                Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                                When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                                                The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                                                An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                                                \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                                                Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                                                Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                                                Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                                                Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                                                In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                                                The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                                                Challenges in looking for and creating innovation when teams are distributed.
                                                                                                                                Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                                                I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                                                Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                                                The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                                                Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                                                What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                                                In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                                                The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                                                Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                                                This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                                                Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                                                Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                                                After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                                                This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                                                Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                                                  \n
                                                                                                                                1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                                                2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                                                  Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                                                  She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                                                  She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                                                  You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                                                  \n\n\n\n

                                                                                                                                  Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                                  While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                                                  Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                                                  1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                                                  2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                                                  3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                                                  These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                                                  Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                                                  She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                                                  What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                                  Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                                                  In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                                                  The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                                                  Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                                                  (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                                                  In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                                                  A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                                                  Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                                                  Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                                                  Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                                                  Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                                                  \"\"<\/a><\/figure>\n\n\n\n

                                                                                                                                  Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                                                  If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                                                  As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                                                  This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                                                  As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                                                  As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                                                  \n

                                                                                                                                  Ankit's team is Agile and they follow Scrum. As they have been following Scrum, they report their velocity and progress at the end of the sprint as part of their sprint review and demo to their stakeholders.<\/p>\n\n\n\n

                                                                                                                                  Their business manager, Linda - a very senior person in product management informed them that the product will need a new feature. Their product owner walked them through the requirements, broke down into stories and also started their sprint<\/p>\n\n\n\n

                                                                                                                                  In the subsequent showcase, Linda asked Ankit when are they likely to deliver the feature. This question stumps Ankit. More worryingly, all the velocity numbers that looked great in earlier showcases seem to suggest they will complete the feature fast; whereas the team is not sure of many things.<\/p>\n\n\n\n

                                                                                                                                  What will you advise Ankit to do? How should he approach planning and what should he inform Linda and other stakeholders.<\/p>\n","post_title":"CHOW #96- A tricky Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-96-tricky-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:20:30","post_modified_gmt":"2024-01-25 11:20:30","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9971","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":9968,"post_author":"14","post_date":"2018-03-26 10:50:41","post_date_gmt":"2018-03-26 05:20:41","post_content":"\n

                                                                                                                                  This blog is more to share an observation and get inputs from as many folks as possible on sprint planning:<\/p>\n\n\n\n

                                                                                                                                  Often, teams do their sprint planning in the following way:<\/p>\n\n\n\n

                                                                                                                                  1. There are a set of stories (mostly) ready for an upcoming sprint.
                                                                                                                                  2. Hence, the teams estimate their stories to pick a few stories from the backlog
                                                                                                                                  3. The team uses story points - adopting Fibonacci series (I have not come across anything else!)
                                                                                                                                  4. They may play planning poker, or, someone from the team proposes a number.
                                                                                                                                  5. The team estimates stories and then pick stories until their velocity is reached.
                                                                                                                                  6. Their velocity is the number that they have completed - could range from just completing development to some stories actually seen by users. For new teams, velocity is a number that the team may find reasonably impressive enough to tell outside.<\/p>\n\n\n\n

                                                                                                                                  Many teams that follow the above routine (or its minor variations) have been exposed to some form of Agile practices. Teams that do this, feel they are just following a routine and struggle to answer the following questions:<\/p>\n\n\n\n

                                                                                                                                  1. Why plan for the sprint?
                                                                                                                                  2. What do the teams expect to do with the sprint plan?
                                                                                                                                  3. And, Why 'estimate' the stories?<\/p>\n\n\n\n

                                                                                                                                  If you are looking for ways to re-boot your planning, consider the below<\/p>\n\n\n\n

                                                                                                                                  1. Focus on a key goal for the sprint:<\/strong><\/p>\n\n\n\n

                                                                                                                                  The purpose of sprint planning must be re-focused to identify the value provided to the user at the end of a sprint.<\/p>\n\n\n\n

                                                                                                                                  Sprint planning, then, can identify tasks that need to be done in the sprint to provide that value to users. The value could be stabilizing a feature that has lots of bugs, or developing a functionality that users will like providing feedback on. Without an overall goal for the sprint - the sprint planning process will start weaker.<\/p>\n\n\n\n

                                                                                                                                  2. Keep your planning appropriately light:<\/strong><\/p>\n\n\n\n

                                                                                                                                  Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.<\/p>\n\n\n\n

                                                                                                                                  Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                                                  Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                                                  3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                                                  Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                                                  Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                                                  In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                                                  Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                                                  Remember,<\/p>\n\n\n\n

                                                                                                                                  Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                                                  Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                                                  However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                                                  A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                                                  Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                                                  My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                                                  In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                                                  We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                                                  1. Build your persona well
                                                                                                                                  Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                                                  2. Focus on framing the problem
                                                                                                                                  Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                                                  3. Generate multiple options for the same problem
                                                                                                                                  Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                                                  This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                                                  Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                                                  Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                                                  The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                                                  In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                                                  How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                                                  Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                                  When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                                                  The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                                                  An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                                                  \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                                                  Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                                                  Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                                                  Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                                                  Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                                                  In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                                                  The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                                                  Challenges in looking for and creating innovation when teams are distributed.
                                                                                                                                  Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                                                  I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                                                  Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                                                  The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                                                  Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                                                  What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                                                  In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                                                  The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                                                  Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                                                  This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                                                  Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                                                  Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                                                  After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                                                  This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                                                  Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                                                    \n
                                                                                                                                  1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                                                  2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                                                    Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                                                    She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                                                    She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                                                    You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                                                    \n\n\n\n

                                                                                                                                    Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                                    While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                                                    Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                                                    1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                                                    2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                                                    3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                                                    These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                                                    Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                                                    She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                                                    What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                                    Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                                                    In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                                                    The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                                                    Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                                                    (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                                                    In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                                                    A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                                                    Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                                                    Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                                                    Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                                                    Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                                                    \"\"<\/a><\/figure>\n\n\n\n

                                                                                                                                    Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                                                    If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                                                    As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                                                    This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                                                    As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                                                    As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                                                    \n

                                                                                                                                    Ankit is a scrum master for a team. Their team is responsible for making small enhancements to their product. They also pick up some new features to be added to their product.<\/p>\n\n\n\n

                                                                                                                                    Ankit's team is Agile and they follow Scrum. As they have been following Scrum, they report their velocity and progress at the end of the sprint as part of their sprint review and demo to their stakeholders.<\/p>\n\n\n\n

                                                                                                                                    Their business manager, Linda - a very senior person in product management informed them that the product will need a new feature. Their product owner walked them through the requirements, broke down into stories and also started their sprint<\/p>\n\n\n\n

                                                                                                                                    In the subsequent showcase, Linda asked Ankit when are they likely to deliver the feature. This question stumps Ankit. More worryingly, all the velocity numbers that looked great in earlier showcases seem to suggest they will complete the feature fast; whereas the team is not sure of many things.<\/p>\n\n\n\n

                                                                                                                                    What will you advise Ankit to do? How should he approach planning and what should he inform Linda and other stakeholders.<\/p>\n","post_title":"CHOW #96- A tricky Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-96-tricky-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:20:30","post_modified_gmt":"2024-01-25 11:20:30","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9971","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":9968,"post_author":"14","post_date":"2018-03-26 10:50:41","post_date_gmt":"2018-03-26 05:20:41","post_content":"\n

                                                                                                                                    This blog is more to share an observation and get inputs from as many folks as possible on sprint planning:<\/p>\n\n\n\n

                                                                                                                                    Often, teams do their sprint planning in the following way:<\/p>\n\n\n\n

                                                                                                                                    1. There are a set of stories (mostly) ready for an upcoming sprint.
                                                                                                                                    2. Hence, the teams estimate their stories to pick a few stories from the backlog
                                                                                                                                    3. The team uses story points - adopting Fibonacci series (I have not come across anything else!)
                                                                                                                                    4. They may play planning poker, or, someone from the team proposes a number.
                                                                                                                                    5. The team estimates stories and then pick stories until their velocity is reached.
                                                                                                                                    6. Their velocity is the number that they have completed - could range from just completing development to some stories actually seen by users. For new teams, velocity is a number that the team may find reasonably impressive enough to tell outside.<\/p>\n\n\n\n

                                                                                                                                    Many teams that follow the above routine (or its minor variations) have been exposed to some form of Agile practices. Teams that do this, feel they are just following a routine and struggle to answer the following questions:<\/p>\n\n\n\n

                                                                                                                                    1. Why plan for the sprint?
                                                                                                                                    2. What do the teams expect to do with the sprint plan?
                                                                                                                                    3. And, Why 'estimate' the stories?<\/p>\n\n\n\n

                                                                                                                                    If you are looking for ways to re-boot your planning, consider the below<\/p>\n\n\n\n

                                                                                                                                    1. Focus on a key goal for the sprint:<\/strong><\/p>\n\n\n\n

                                                                                                                                    The purpose of sprint planning must be re-focused to identify the value provided to the user at the end of a sprint.<\/p>\n\n\n\n

                                                                                                                                    Sprint planning, then, can identify tasks that need to be done in the sprint to provide that value to users. The value could be stabilizing a feature that has lots of bugs, or developing a functionality that users will like providing feedback on. Without an overall goal for the sprint - the sprint planning process will start weaker.<\/p>\n\n\n\n

                                                                                                                                    2. Keep your planning appropriately light:<\/strong><\/p>\n\n\n\n

                                                                                                                                    Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.<\/p>\n\n\n\n

                                                                                                                                    Over a shorter horizon, as in sprints - teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties - use their prior experience to task out and review how many of the tasks - and hence the stories will get completed to meet the goal.<\/p>\n\n\n\n

                                                                                                                                    Focussing on story points and 'estimating' may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.<\/p>\n\n\n\n

                                                                                                                                    3. Try different approaches to forecasting your team progress - including story count:<\/strong><\/p>\n\n\n\n

                                                                                                                                    Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.<\/p>\n\n\n\n

                                                                                                                                    Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.<\/p>\n\n\n\n

                                                                                                                                    In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.<\/p>\n\n\n\n

                                                                                                                                    Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish - say a story or two at least per person in the team.<\/p>\n\n\n\n

                                                                                                                                    Remember,<\/p>\n\n\n\n

                                                                                                                                    Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case - they will need to adapt their planning for medium to longer term via release planning.<\/p>\n\n\n\n

                                                                                                                                    Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.<\/p>\n\n\n\n

                                                                                                                                    However, at a sprint level, and in teams that have a backlog not fully visible - lighter weight approaches to sprint planning may bring life back into your sprint planning process.<\/p>\n","post_title":"Re-boot your Sprint Planning","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"re-boot-sprint-planning","to_ping":"","pinged":"","post_modified":"2024-01-25 11:22:36","post_modified_gmt":"2024-01-25 11:22:36","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9968","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9647,"post_author":"14","post_date":"2017-12-11 12:16:20","post_date_gmt":"2017-12-11 06:46:20","post_content":"\n

                                                                                                                                    A backlog must resemble a good folktale- that people will talk about after they have listened to it, allowing freedom to interpret and be able to be told in multiple variations without changing the outcome.<\/p>\n\n\n\n

                                                                                                                                    Product Owners play a direct role in creating backlogs that teams can own and understand the problem that they are trying to solve. Product Owners need to become story tellers than requirement specialists.<\/p>\n\n\n\n

                                                                                                                                    My experience in working with teams has been that the backlog usually appears empty or stuffed with disparate items early in the lifecyle. Once clarity is available on what needs to be done, the backlog directly moves to having stories that are picked up by the team for delivery based on a quarterly planning cycle.<\/p>\n\n\n\n

                                                                                                                                    In that sense, backlogs end up resembling specifications. This blog makes a case to evolve the backlog deliberately and carefully.<\/p>\n\n\n\n

                                                                                                                                    We suggest a specific mechanism to develop and refine a backlog. This involves tweaking the entire backlog building process, building iteratively. Product Owners must strive to understand how they need to impact the customer and what they are hoping to learn from.<\/p>\n\n\n\n

                                                                                                                                    1. Build your persona well
                                                                                                                                    Defining a persona and the specific problem a product is trying to solve for the persona is a great way to start creating good backlogs. Earlier blogs have covered more about personas - but I would like to just re-iterate that create personas only after you have met at least 8-12 users; do not create phantom personas without meeting adequate users. Learn about your users.<\/p>\n\n\n\n

                                                                                                                                    2. Focus on framing the problem
                                                                                                                                    Often, a backlog defines the solution that needs to get built. Use the LEVER<\/a> approach mentioned earlier in our blogs to slow down and explain the problem that the user needs help with. Capturing underlying assumptions and beliefs of the the product team and stating them clearly helps in building hypotheses. This helps clarify your observations, facts that user agrees to from assumptions and ideas that you believe will solve the problem.<\/p>\n\n\n\n

                                                                                                                                    3. Generate multiple options for the same problem
                                                                                                                                    Typically, teams quicky decide on the one great solution that they think is going to help the user. Acknowledging that there should multiple ways to solve a problem, helps you test what users may find valuable.
                                                                                                                                    This typically changes the whole team's perception of a delivery as a means to learn from the user - than as a way to ship stuff out of the door.<\/p>\n\n\n\n

                                                                                                                                    Doing these three things will help in creating backlogs that teams can draw energy from and where teams acknowledge they have a story teller for a product owner.<\/p>\n","post_title":"The Story Teller","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-story-teller","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:07","post_modified_gmt":"2024-01-25 11:23:07","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9647","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":9649,"post_author":"14","post_date":"2017-12-11 07:05:28","post_date_gmt":"2017-12-11 01:35:28","post_content":"\n

                                                                                                                                    Amit is a lead for a team. His team has a clear charter to improve the quality of client engagement information available to their sales team. Towards this, the team is working with analytics and the latest in software - machine learning.<\/p>\n\n\n\n

                                                                                                                                    The team is following Agile and does quarterly planning; and here-in lies their challenge. Earlier, quarterly planning used to be figuring out how much the team feels they can do. They knew what they were buildin in a reasonable way<\/p>\n\n\n\n

                                                                                                                                    In this current charter, the team does not know what they are going to do - they have an approach and clarity on outcomes, but do not know what will be their deliverable at the end of next three months. Several team members feel, given that they are also exploring what can be done, they can not commit to a deliverable or its timeline.<\/p>\n\n\n\n

                                                                                                                                    How do you think this team must approach their planning process?<\/p>\n\n\n\n

                                                                                                                                    Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                                    When a product build has clarity on expected outcomes, but not on the actual approach; the entire build can be initially run as a series of experiments that filter out less viable options.
                                                                                                                                    The team can then focus on jotting down what they intend to validate and learn from each experiment (hypotheses + observation) and plan for a timeline to learn and pivot as needed. The release planning will then be a series of time-boxed experiments that lead to one or more feature build outs.<\/p>\n","post_title":"CHOW #85- Planning with a not so clear backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-85-planning-not-clear-backlog","to_ping":"","pinged":"","post_modified":"2024-01-25 11:23:45","post_modified_gmt":"2024-01-25 11:23:45","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=9649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":989585,"post_author":"14","post_date":"2017-08-27 17:24:55","post_date_gmt":"2017-08-27 11:54:55","post_content":"\n

                                                                                                                                    An advantage of considering Design Thinking as an Innovation LEVER is that it clarifies what Design Thinking actually is - and what it is not.<\/p>\n\n\n\n

                                                                                                                                    \"LEVER\"<\/a><\/figure>\n\n\n\n

                                                                                                                                    Design Thinking provides a structure - for individuals and teams to look closely at challenges, understand the problem before moving to create a solution. Hence, practising Design Thinking will also need tools and skills required to use the structure effectively.<\/p>\n\n\n\n

                                                                                                                                    Each step of creating a response has tools that have been used for ages. Tools for research, for generating ideas, to validate assumptions and to build solutions incrementally while getting constant feedback.<\/p>\n\n\n\n

                                                                                                                                    Effective use of this structure requires multiple skills - a strength that only a poly-skilled team can bring in. It is critical to build facilitation skills for effective collaboration across teams and stakeholders with these skills and knowledge.<\/p>\n\n\n\n

                                                                                                                                    Without these tools and the collaboration skills, the structure that Design Thinking provides will end up being procedural - risking Design Thinking being tagged as a fad.<\/p>\n\n\n\n

                                                                                                                                    In subsequent posts, I plan to write about:<\/p>\n\n\n\n

                                                                                                                                    The relevance of Design Thinking, Agile and DevOps in the lifecycle of businesses (are they the Three musketeers of innovation?)
                                                                                                                                    Challenges in looking for and creating innovation when teams are distributed.
                                                                                                                                    Introducing Design Thinking in to teams - and in existing environments.<\/p>\n\n\n\n

                                                                                                                                    I will greatly appreciate you writing and responding on this post - to further me on the learning path.<\/p>\n","post_title":"Design Thinking - What it is and how to start using it (contd)...","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"closed","post_password":"","post_name":"design-thinking-what-it-is-and-how-to-start-using-it-contd","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:05","post_modified_gmt":"2024-01-25 11:24:05","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/blogs\/?p=4586","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7424,"post_author":"14","post_date":"2017-08-20 16:51:01","post_date_gmt":"2017-08-20 11:21:01","post_content":"\n

                                                                                                                                    Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints \u2013 the team has been regularly preparing stories for sprints. As part of sprint planning \u2013  they estimate stories using story points and track velocity.<\/p>\n\n\n\n

                                                                                                                                    The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details \u2013 as they are agile and will not be able to plan ahead. They also point out that stories are not ready and hence they will not be able to estimate. They are clear in the view that the product owner has provided details that are at a very high level \u2013 with some very basic acceptance criteria.<\/p>\n\n\n\n

                                                                                                                                    Rohit and the product owner are at  a loss on what to do. They have thought about doing an initial plan and provide it to stakeholders without involving the team.  Rohit has a sense of current velocity of the team based on the sizing they do in each sprint. Should Rohit use that?<\/p>\n\n\n\n

                                                                                                                                    What will you advise Rohit to do?<\/p>\n","post_title":"CHOW #73- Painting the big picture","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-73-painting-big-picture","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:26","post_modified_gmt":"2024-01-25 11:24:26","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7424","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7287,"post_author":"14","post_date":"2017-08-20 12:29:37","post_date_gmt":"2017-08-20 06:59:37","post_content":"\n

                                                                                                                                    In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen \u2013 and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals \u2013 and asked for a time frame for when most of these would get done.<\/p>\n\n\n\n

                                                                                                                                    The agile ceremonies \u2013  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning<\/p>\n\n\n\n

                                                                                                                                    Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.<\/p>\n\n\n\n

                                                                                                                                    This is the place where release planning is most helpful. And more importantly this is the place where  relative sizing is relevant.<\/p>\n\n\n\n

                                                                                                                                    Relative sizing \u2013 the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go \u2013 over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.<\/p>\n\n\n\n

                                                                                                                                    Once a team plans for a release \u2013 the need to size a story should not be there (unless something totally new comes up).<\/p>\n\n\n\n

                                                                                                                                    After a release planning is done,  sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels  can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint.  There may be stories that team feels they may start but not finish \u2013 those are stories that are not part of the sprint commitment.<\/p>\n\n\n\n

                                                                                                                                    This way the team can focus on completion. Velocity becomes emergent.<\/p>\n\n\n\n

                                                                                                                                    Over a period of time, teams will find that predictability is valued \u2013  allows stakeholders to expect and react better. In summary, these are my suggestions:<\/p>\n\n\n\n

                                                                                                                                      \n
                                                                                                                                    1. Adapt to ambiguity; use relative sizing to plan at release level \u2013 not during sprint planing.<\/li>\n\n\n\n
                                                                                                                                    2. During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.<\/li>\n<\/ol>\n","post_title":"Two reasons to stop sizing during sprints","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-reasons-stop-sizing-sprints","to_ping":"","pinged":"","post_modified":"2024-01-25 11:24:52","post_modified_gmt":"2024-01-25 11:24:52","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7287","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":6203,"post_author":"14","post_date":"2017-05-17 17:00:20","post_date_gmt":"2017-05-17 11:30:20","post_content":"\n

                                                                                                                                      Divya is a business analyst \u2013  working with clients, understanding requirements and ensuring that is understood by the team when they build. She has eight years experience and has been working in teams that you manage for the past couple of years.<\/p>\n\n\n\n

                                                                                                                                      She has reached out to you, and as part of the conversation you find that she is bored with the usual cycle of  writing requirement documents and getting them signed off and then working with teams only to face questions, ideas, suggestions from the team and clients \u2013 many of which she had also expressed during the initial stages.<\/p>\n\n\n\n

                                                                                                                                      She thinks her only next step is to start slowly managing teams; but prefers to work on solutions than managing projects. She then proceeds to ask what she can do differently in her role.<\/p>\n\n\n\n

                                                                                                                                      You and she are planning to catch up in another couple of days. Can you give her a ring-side view of what she can do differently in her teams and what kind of skills she can plan to pick up, to enjoy her business analyst role better?<\/p>\n\n\n\n


                                                                                                                                      \n\n\n\n

                                                                                                                                      Our point of view to this Chow will be available on 30-May-16. We will love to interact with you through the comments section.<\/p>\n\n\n\n

                                                                                                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                                      While the traditional role of a business analyst has been reduced to collecting requirements from clients, documenting them and then coordinating to get them developed by the team \u2013 things are changing pretty rapidly.<\/p>\n\n\n\n

                                                                                                                                      Business Analysts will now need to don the role of facilitators in the solution development space. For this, they will need to actively develop these new areas:<\/p>\n\n\n\n

                                                                                                                                      1. Facilitation skills \u2013 Bringing teams together, so that relevant stakeholders agree on problems and solutions, with each stakeholder (development, product owner, sometimes end user too) providing their perspective \u2013 ideas, approaches, risks, challenges<\/p>\n\n\n\n

                                                                                                                                      2. Design Thinking skills: Techniques that help in unearthing problems and validating solutions end to end, thereby reducing wasted software creation<\/p>\n\n\n\n

                                                                                                                                      3. Release & Development Management: As the proxy owner of their project from a functional perspective, Divya can and must develop abilities to come up with options on releases that will create value to end customer (not just based on constraints in development)<\/p>\n\n\n\n

                                                                                                                                      These are areas where traditional Business Analyst role is not taken in to; and will require focus on developing skills in multiple areas. Apart from this, is the \u2018taken for granted\u2019 domain awareness (I , however, feel this awareness is confused with expertise, which may not be necessary)<\/p>\n","post_title":"Help a Business Analyst Pivot","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"help-business-analyst-pivot","to_ping":"","pinged":"","post_modified":"2024-01-25 11:25:22","post_modified_gmt":"2024-01-25 11:25:22","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=6203","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7385,"post_author":"14","post_date":"2017-04-09 15:36:50","post_date_gmt":"2017-04-09 10:06:50","post_content":"\n

                                                                                                                                      Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client.<\/p>\n\n\n\n

                                                                                                                                      She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board \u2013 her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration \u2013 given that the client is important and first in the segment.<\/p>\n\n\n\n

                                                                                                                                      What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.<\/p>\n\n\n\n

                                                                                                                                      Suggested Solution:<\/strong><\/p>\n\n\n\n

                                                                                                                                      Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management.<\/p>\n\n\n\n

                                                                                                                                      In this case, Swathi must consider the volatility and completeness of the requirements in the backlog. Volatility \u2013 as the name suggests, strives to understand the probability of requirements getting changed. A good way to understand this would be to understand the realm of users \/ personas and how well we have understood them. If volatility is high, a product rollout must plan to pivot fast or use lo-fi techniques to reduce volatility.<\/p>\n\n\n\n

                                                                                                                                      The other area to watch out for is completeness. While this is usually better identified when requirements are known and known to be unknown, product owners get blind sided by assumptions they make. So, it is important to carefully review the grounds on which assumptions are taken.<\/p>\n\n\n\n

                                                                                                                                      Swathi must review her backlog and work with her customer to identify areas where there will be flux based on above two parameters and appropriately change the game.<\/p>\n","post_title":"CHOW #55\u2013 How should Swathi handle changing requirements","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-55-swathi-handle-changing-requirements","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:00","post_modified_gmt":"2024-01-25 11:30:00","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":7371,"post_author":"14","post_date":"2017-04-09 15:19:35","post_date_gmt":"2017-04-09 09:49:35","post_content":"\n

                                                                                                                                      (Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions)<\/em><\/h6>\n\n\n\n

                                                                                                                                      In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases<\/a> in an agile project.<\/p>\n\n\n\n

                                                                                                                                      A problem that is well understood leads to a better solution. Applying design thinking<\/a> techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the problem context that they are trying to solve. Visual story telling along with story mapping- two simple but powerful techniques helps product owners and team to convey a product\u2019s vision alongside  its existential context. These techniques change the way people participate and help agile projects start well.<\/p>\n\n\n\n

                                                                                                                                      Product and business analysts have a responsibility to consolidate what they have learnt about the problem they are trying to solve. A key activity in this endeavour is to bring clarity on the personae involved in the problem context, their motivations and the problem that the product is trying to solve in the persona\u2019s context.<\/p>\n\n\n\n

                                                                                                                                      Good persona building involves carefully observing and synthesizing a proper representation of users. The skills required to do that are different from the analytical, technical and organizational skills for building the solution \u2013 inquiry based research, ethnographic observation, awareness of biases, consolidation and facilitation skills<\/a>play a key role here. These can be learnt and developed through practice. Understanding and building personas better is a vast topic by itself and we will cover some of it in subsequent blogs. We will just get introduced the outcome of such a persona building exercise (Visual story telling and user story mapping)<\/p>\n\n\n\n

                                                                                                                                      Visual stories about personas and their motivation are powerful. These stories provide a platform for strangers to be part of the journey, sharing their anecdotal experience, learn from the story and enrich the overall story narrative. Visual stories that are available on the floor of a agile project or a place where research validation is being done becomes a conversation magnet \u2013 around which problems and solutions are discussed.<\/p>\n\n\n\n

                                                                                                                                      Chalking out personas visually, require doodling skills \u2013 sketching the user, their world, the tasks they do, their goals and motivations along with details that are appropriate to be highlighted. I have found that it is useful to go back to our primary school skills to learn the basics of observation, drawing and thinking visually. When starting to think visually, it is good to doodle some faces, simplify objects that are most important and leave out unnecessary details. Usually, the persona and the outcome of the persona\u2019s task and the emotion they will be in at the end of the task based on its outcome are the key factors in thinking visually. Putting these details in help stakeholders to inquire more and learn to arrive at one or more solution approaches. Adding a expression conveys emotions deeply and achieves good outcomes in lo-fi visual doodles.<\/p>\n\n\n\n

                                                                                                                                      \"\"<\/a><\/figure>\n\n\n\n

                                                                                                                                      Developed personas can be validated only when a story is told and the story resonates with the listeners. And, this is where user story maps fit in. While visual stories about persona sets the context, the story map provides a broad perspective of the solution and the underlying priorities.Creating a story map is simple, easy to learn, but takes practice to do it effectively. To create a story map, have some cards in your hand and start detailing out the tasks that the persona will do.<\/p>\n\n\n\n

                                                                                                                                      If it is a bank manager persona, a day in the life at work could be meeting customers, approving cash requests, reviewing loan requests and engaging business stakeholders. These are all tasks. Only a part of the persona\u2019s tasks could be part of the product or solution that you are trying to address. Focus on that and as mentioned before, build as much context about how the user will work (busy, need to switch attention between different tasks etc.)<\/p>\n\n\n\n

                                                                                                                                      As you organize your tasks in a sequence, you will find the list wide. Step back to identify variations you will need to add. These are details that go deep. Aggregate tasks by goals. As you aggregate tasks closer by related goals, you will find that there is a set of tasks related placed closer together and sets of cards in another dimension that are variations and exceptions for each task group going deep. For example, reviewing loan requests could also mean understanding prior bank histories and exploring opportunities to place new products in front of the customer. These are all related tasks towards the same goal of completing loan request reviews.<\/p>\n\n\n\n

                                                                                                                                      This is where the fun begins, typically stakeholders are now able to walk across the wall, view the tasks and interpret tasks closer to each other as related and look at possible variations. Conversations on relative priorities become easier. Visual stories about the persona are good contextual reference here as they set the persona\u2019s goals and emotions in context of the tasks.<\/p>\n\n\n\n

                                                                                                                                      As priorities emerge and are agreed upon, shuffle  more important cards higher up. Doing this will let a skeleton structure of the solution to be available and on stakeholder agreement becomes a candidate release goal. And these cards, become usually the epics and large stories that kick-start the project.<\/p>\n\n\n\n

                                                                                                                                      As you fill up the matrix with cards, start identifying gaps, inter-relationships and variations. Once there is enough on the wall, it will be useful to get opinions about the story map; from project team, stakeholders and whereever possible persona representatives. Well formed story maps, laid out visually give a clear picture of the problem and the approach to solution forming the backbone of release planning and prioritisation<\/p>\n","post_title":"Two techniques to explain your Product Vision","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"two-techniques-explain-product-vision","to_ping":"","pinged":"","post_modified":"2024-01-25 11:30:57","post_modified_gmt":"2024-01-25 11:30:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=7371","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                                                                                      Harish Achappa Kallira

                                                                                                                                      Page 1 of 2 1 2