With an intimate knowledge of the product and strong communication skills, some analysts will tend to shift into product owner roles. This is especially common on large projects that make use of a hierarchy of product owners. Someone with product manager on her business card, for example, may act as the chief product owner for the overall product, spending most of her time looking outward at users and the market. An individual with analyst on her business card, on the other hand, may act as product owner for the various teams, working with the chief product owner to translate her vision into product backlogs for her teams.
Many teams find that having an analyst on the team continues to be very beneficial, although the ways in which the analyst works will change. On traditionally managed projects, the analyst's mission seemed to be to get as far ahead of the team as possible. On a Scrum project, just-in-time analysis becomes the goal. The analyst's new aim is to stay as slightly ahead of the team as possible while still being able to provide useful information to the team about current and near-term features.
Analysts can be instrumental in achieving the goal of shifting the emphasis from writing about requirements to talking about them. Because analysts are not working as far ahead of the team as they may be used to, they need to become more comfortable sharing information with the team more informally, rather than through a large document. As much information as possible should be shared through verbal discussion, but analysts will still need to document some requirements, especially when working on a distributed team. Often though, what the analyst writes will be less formal—more often a wiki than a document with a signature page.
On traditional projects, analysts often become intermediaries through whom other team members and the product owner communicate. On a Scrum project the analyst should become more a facilitator of team-product owner discussion than an intermediary. Team members and product owners need to talk. Rather than be the conduit for all conversation, the good agile analyst focuses on making sure those conversations are as productive as possible given the time constraints the team or product owner may be under. This may mean that the analyst steers the product owner and team toward talking about one user story rather than another because that is where there is more risk of going astray. Or it may mean that the analyst conveys a top-level understanding of a new feature to the team before bringing the team and product owner together to discuss the details.
On a traditional project, an analyst may say to the team,"I've talked to our key stakeholder, understand what he wants, and have written this document describing it in detail." By contrast, on a Scrum project, the same analyst should say, "I've spoken to our product owner and have a feeling for what he's after. I wrote these six user stories to give you a start, and I've got a bunch of additional questions to ask the product owner. But I want to make sure that I bring along a couple of you when we have those discussions."
With all this talk of analysts looking ahead, it can be tempting to think that analysts work a sprint ahead of the team. They don't. Gregory Topp, an analyst with Farm Credit Services of America, describes how using Scrum has allowed him to concentrate on the current sprint: "Before Scrum, I had to focus on requirements that were not going to be developed for several weeks, if not months. Now, I focus on the current sprint (two weeks for us), so more time can be spent on user story details, development, and testing." An analyst's first priority is to achieve the goals of the current sprint. An analyst on a Scrum team will assist in testing, will answer questions (or track down answers to questions) about features being developed, will participate fully in all regular sprint meetings, and so on.
However, it is quite possible that these activities will not fully consume the analyst's time. Time that is not needed to complete the work of the current sprint can be used to look ahead. However, being a part of the team on this sprint and spending some time looking ahead is not the same as working a sprint ahead of the team. Topp explains how jumping too far ahead actually put him behind: "I tried working ahead a sprint or two, defining user story details. I found that this caused the current sprint to suffer. I also found that many times the details of a user story changed by the time the team actually started working on the story."
A common question is whether the effort analysts spend looking ahead should be included on the sprint backlog. My recommendation is to include on the sprint backlog any specific analysis tasks that can be identified during sprint planning. For example, suppose the team is working on an application that approves or rejects loan applications. If the product owner and team agree that the next sprint will include work on calculating the applicant's credit score, then preliminary analysis tasks related to that should be identified, estimated, and included in the sprint backlog. On the other hand, if the next sprint's work is unknown, no specific tasks related to the next sprint should be included on the sprint backlog. Overall, many analysts enjoy the change to Scrum even though they relinquish the role of sole interpreter of customer desires. Two years after adopting Scrum, Topp commented on how his relationship with others on the team had changed.
Because we are all on the same team and all work on the same user stories at the same time, the team seems to have more unity. Before using Scrum, it seemed each function (analyst, programmer, tester, DBA) was done in a silo. There was more fingerpointing when in that mode. Now using Scrum, the team is all focused on a small set of stories. The finger-pointing has been eliminated with an "as a team" mindset.
Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010
Many teams find that having an analyst on the team continues to be very beneficial, although the ways in which the analyst works will change. On traditionally managed projects, the analyst's mission seemed to be to get as far ahead of the team as possible. On a Scrum project, just-in-time analysis becomes the goal. The analyst's new aim is to stay as slightly ahead of the team as possible while still being able to provide useful information to the team about current and near-term features.
Analysts can be instrumental in achieving the goal of shifting the emphasis from writing about requirements to talking about them. Because analysts are not working as far ahead of the team as they may be used to, they need to become more comfortable sharing information with the team more informally, rather than through a large document. As much information as possible should be shared through verbal discussion, but analysts will still need to document some requirements, especially when working on a distributed team. Often though, what the analyst writes will be less formal—more often a wiki than a document with a signature page.
On traditional projects, analysts often become intermediaries through whom other team members and the product owner communicate. On a Scrum project the analyst should become more a facilitator of team-product owner discussion than an intermediary. Team members and product owners need to talk. Rather than be the conduit for all conversation, the good agile analyst focuses on making sure those conversations are as productive as possible given the time constraints the team or product owner may be under. This may mean that the analyst steers the product owner and team toward talking about one user story rather than another because that is where there is more risk of going astray. Or it may mean that the analyst conveys a top-level understanding of a new feature to the team before bringing the team and product owner together to discuss the details.
On a traditional project, an analyst may say to the team,"I've talked to our key stakeholder, understand what he wants, and have written this document describing it in detail." By contrast, on a Scrum project, the same analyst should say, "I've spoken to our product owner and have a feeling for what he's after. I wrote these six user stories to give you a start, and I've got a bunch of additional questions to ask the product owner. But I want to make sure that I bring along a couple of you when we have those discussions."
With all this talk of analysts looking ahead, it can be tempting to think that analysts work a sprint ahead of the team. They don't. Gregory Topp, an analyst with Farm Credit Services of America, describes how using Scrum has allowed him to concentrate on the current sprint: "Before Scrum, I had to focus on requirements that were not going to be developed for several weeks, if not months. Now, I focus on the current sprint (two weeks for us), so more time can be spent on user story details, development, and testing." An analyst's first priority is to achieve the goals of the current sprint. An analyst on a Scrum team will assist in testing, will answer questions (or track down answers to questions) about features being developed, will participate fully in all regular sprint meetings, and so on.
However, it is quite possible that these activities will not fully consume the analyst's time. Time that is not needed to complete the work of the current sprint can be used to look ahead. However, being a part of the team on this sprint and spending some time looking ahead is not the same as working a sprint ahead of the team. Topp explains how jumping too far ahead actually put him behind: "I tried working ahead a sprint or two, defining user story details. I found that this caused the current sprint to suffer. I also found that many times the details of a user story changed by the time the team actually started working on the story."
A common question is whether the effort analysts spend looking ahead should be included on the sprint backlog. My recommendation is to include on the sprint backlog any specific analysis tasks that can be identified during sprint planning. For example, suppose the team is working on an application that approves or rejects loan applications. If the product owner and team agree that the next sprint will include work on calculating the applicant's credit score, then preliminary analysis tasks related to that should be identified, estimated, and included in the sprint backlog. On the other hand, if the next sprint's work is unknown, no specific tasks related to the next sprint should be included on the sprint backlog. Overall, many analysts enjoy the change to Scrum even though they relinquish the role of sole interpreter of customer desires. Two years after adopting Scrum, Topp commented on how his relationship with others on the team had changed.
Because we are all on the same team and all work on the same user stories at the same time, the team seems to have more unity. Before using Scrum, it seemed each function (analyst, programmer, tester, DBA) was done in a silo. There was more fingerpointing when in that mode. Now using Scrum, the team is all focused on a small set of stories. The finger-pointing has been eliminated with an "as a team" mindset.
Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010
|
|
0 comments
Post a Comment