User Stories Webinar Q and A Stream
Rally's Agile coaches and product experts answer your toughest questions.
Why "stories" and not "use cases"? What's the difference?
Ronica Roth: User stories and use cases both help you manage requirements. User Stories focus more on encouraging conversation and flexibility around the requirements and also emphasize business value and priorities of feature implementation.
What method is used to estimate the business value for a given work item/feature/story? And what units (dollars? market share?)
Ronica Roth: There is no one way to estimate or indicate value. In fact, I have found that many organizations struggle with this piece. You can use something as specific as dollars--I worked at an investment company that did that well. Or you can use something as simple as rating stories on a scale of 1-5 along several vectors, such as user value, market value, competitive value, strategic value. Whatever vectors are relevant to your world. Because so few orgs have gotten good at measuring value, any value indicator is usually better than none.
Could you mention which are the difference between Velocity and Capacity pls?
Ronica Roth: Velocity is a historical measure of the story points the team has delivered per iteration. Capacity is the amount of hours the team has available in a given iteration, considering vacation, work that we don't plan in the iteration (such as production support or answering emails), and commitments outside the team.
When do you typically decide the story point value of a user story?
Eric Willeke: I recommend the team gives the PO an idea of the value ahead of time and "commits" to the value during the sprint planning as part of the sprint commitment.
How does tratitional product manager transition to Product Owner role and become effective at it?
Ronica Roth: Often the difference is that a PO spends more time with the team. So that's a shift. I think the biggest shift is getting used to just-in-time elaboration of requirements. Instead of thinking in terms of learning all reqs up front, we must shift our mindset to ask, How can we deliver something fast and learn via feedback.
Is the produt owner involved in breaking down stories at the sprint level?
Ronica Roth: Absolutely. As a PO, I want to be as involved as possible. They are my stories! That said, I may need the help of the team to see how to break down stories. And, I want to be involved so I can ensure that the split stories still meet my needs (and the needs of my stakeholders/customers). And I need to own ranking of the broken down stories.
What if your stakeholders always want sign-off on detail requirements before product can be developed?
Eric Willeke: This is a difficult political problem to be worked through as a trust-building exercise. Over time and successful deliveries, the customers should come to trust the teams to implement based on the lighter-weight understanding in the form of the user stories, or even epics.
Who are all included in backlog grooming session?
Eric Willeke: Where possible, include the entire team along with with product owner and scrum master. Some teams set aside a standing meeting time for this halfway through a sprint to ensure the product owner gets attention.
My team has a User Experience Designer, and I am the Business Analyst. So in this type of team, would the BA stop at the level of the user story, and then let the User Experience Designer define the acceptance criteria?
Eric Willeke: Rather than view it as "one person stopping, another person starting", try to instead view it as "I will work with my experience designer (and the rest of the development team) to craft the entirety of the story." In general, avoid the idea of hand offs.
I am in an environment where team members typically only serve in 1 role (DA, ETL, QA etc.). To keep people busy for the entire sprint, it requires breaking up user stories into smaller tasks. Do you recommend having two levels of granularity (user stories)?
Ronica Roth: User stories should remain clearly focused on the WHAT, and be value-oriented. In sprint planning, the team then identifies the tasks needed to implement the stories. I don't recommend worrying so much about keeping people busy. Instead, worry about what it will take to deliver value, and trust the team to coordinate and collaborate throughout the sprint. That said, you can use story size and story and task sequencing to keep the work moving. That is, you might want to tackle a small story early in the sprint, so you can get it to test quickly, and create a smooth flow of work.
Can a QA member can write an User Sotry?. As a QA member, I need to prepare the QA environmet, etc?
Eric Willeke: Anybody can write a story, the product owner decides where to put it in the backlog. Where possible, avoid stories that reference members of the team and capture them in terms of the user value.
Who really decides the points to be alloted for a particular user story? How do you resolve disagreements between the PO & Scrummaster where the PO wants a quick & dirty fix and Scrum master/developers insist on a "proper" fix?
Eric Willeke: Those are two different questions. The Product Owner should accept input from the team as to the right way to fix a problem, but should be able to make the decision unless it hurts the teams ability to make future commitments. The team owns the point estimates, and uses those estimates to inform its sprint-level commitments. The story points and velocity aren't transportable outside the team.
How is the Scrum Master empowered to ensure that the Sprint process keeps a forward momentum?
Eric Willeke: The ScrumMaster is not a manager nor does the ScrumMaster direct or control the team. Instead, the individual should work with the team to help the team work together more effectively, stay focused on the right things, and all continue executing Scrum according to its values.
Most of the big Enterprises have silo roles ... and they are not great at wearing many hats. How do you change the status-quo?
Eric Willeke: We start by getting the people together working as teams and give them joint responsibility and accountability for delivery. Over time, they will learn each others' roles and work together more effectively.
Shouldn't the true business owner own the backlog instead of a BA? Assuming both are on the project?
Eric Willeke: The product owner is the owner of the backlog. Ideally, this person is a full time member of the business and not a BA "playing" the role.
PO needs to maintain the communication with the team and be able to feel comfortable in the decision making role?
Eric Willeke: Correct. There should be no real "walls" between the PO and the team.
where does a technical writer fit in to writing user stories? do they determine acceptance criteria based on the documentation being produced, the product being written on, or both?
Ronica Roth: I have not had the experience of tech writers writing stories. I'd rather have the PO, BA, or team write stories. That said, if TWs are helping write stories, they should be writing them based on working directly with stakeholders and the PO. They should write AC based on input from stakeholders and the PO as well as based on conversations with the team. The more documentation between the user input and the story, the more risk that we'll miss understanding.
How does the traditional Business Analyst role change within the Agile methodology?
Mark Kilby: The business analyst becomes part of the team or can become the Product Owner that maintains the backlog of user stories. What is unique is the decision authority a product owner has.
If you have a BA and a PM, and the BA is the product owner, how is the PM then involved in the agile process?
Mark Kilby: PM may be a scrummaster or may just coordinate staff among multiple agile teams. I've seen both.
Acceptance Criteria and Definition of Done
Who should define acceptance criteria?
Eric Willeke: The entire team contributes to the criteria, but the product owner technically owns the story and thus the acceptance criteria.
Do you create Acceptance Criteria and agree on it, before you size a User Story?
Ronica Roth: In my experience, we evolve AC through conversation. So, as a PO I want to bring stories with AC into planning. Then, as the team tries to size the story, they ask questions. New AC might emerge, and we'll add them to the story.
What do you consider the min/max number of acceptance criteria for a good story
Ronica Roth: I'm not a fan of rules of thumb, but 4 - 10 is probably a good guide. Remember: the AC should indicate what you mean by the story. You need enough to give some guidance. But they should not be a test plan. The testers will take the AC and build a test plan. I think of the AC as the result of the conversation. Write down enough to ensure the team remembers the conversation you had.
Can we have the ACs wrapped into a story card description? Why would we not have the stories on an acceptance criteria level (1 to 1 ratio)
Ronica Roth: You might, if that works for you. But I have found it useful to write a story that simply describes the WHAT, WHO, and WHY. And then to add bullets as AC, which capture the results of conversations.
We often struggle with readiness of a story and there are many stories that change once the iteration starts. What is the recommended framework to manage this?
Ronica Roth: I worked with one organization who created a Definition of Ready. It had something to do with being of a certain size (less than 13 points), of having acceptance criteria, of including a VALUE. If you're experience that pattern of change, I would suspect that there isn't enough conversation with the team during planning. Consider using planning poker to size stories in points. That method usually helps raise assumptions and questions. Does the PO participate in iteration planning? That could be a problem if he/she doesn't. Consider devoting a retrospective to an investigation of why that's happening. Do a root cause analysis.
Regarding the Aceptance criteria and concept of Done that are part of the user stories, which are the difference between these concept?, each user story need to have both?
Rob Pinna: Definition of Done applies to all stories. For example, code checked in, all defects resolved, unit tests passed. AC are specific to the story. For example, the tax for a $100 shopping cart order in the state of Colorado is $6. So you need both, but DOD is a general "checklist" that isn't specified per story. Next webinar discusses this in detail.
How is scope creep defined and addressed in story based development?
Mark Kilby: Acceptance criteria keeps scope locked in during a sprint. Additional scope can be added to the backlog for future sprints and release and sprint planning becomes scope negotiation.
Can we see some examples of acceptance criteria?
Mark Kilby: Check out slide 26 and 27 in this deck: http://www.rallydev.com/user-stories-toolkit-0/
How does agile support feature development that causes multiple cycles of regression testing. Is it best to stall testing and product release to have one regre test cycle, or ramp up test resources and allow multiple regression cycles?
Mark Kilby: We will talk about this more in next webinar on Defintion of Done, but, in short, you want to have testing early and often. I would try to do as much testing as possible each sprint and find ways to do more.
In agile, what is the value or importance of sign-off?
Eric Willeke: In Scrum, the idea of sign-off is replaced with an explicit acceptance of each story by the Product Owner, which typically occurs when the team has satisfied the acceptance criteria pursuant to their definition of done.
So, the development team IS involved in the delineation of the acceptance criteria?
Eric Willeke: Yes.
Particularly focused on the definition of "Done", what do most companies do to handle bugs? Are they identified and fixed before the story is done and accepted or are they placed into the backlog as other stories to be prioritized?
Eric Willeke: It typically depends on when the bug is found. If the bug is found after the story is done (i.e. in another sprint), then it's added to the overall backlog. If the bug is found before the story is done, it is typically represented as "work not finished" and fixed as part of completing the story.
The acceptance criteria and tasks aren't detailed until the sprint in which they are developed/prioritized .. correct?
Eric Willeke: I prefer to use the language "the acceptance criteria aren't detailed until just ahead of the sprint in which they are developed" and agree with the aspect that tasking doesn't typically occur until the sprint planning meeting, or perhaps even into the sprint.
Writing User Stories
When are the user stories put together - before project initiation or after?
Ronica Roth: Product Backlogs evolve. So, during project initiation you might identify initial themes and high-level features or epics. Then, as the team begins iterating, you break down the highest-ranked stories, always with an eye toward breaking off the least valuable pieces and focusing on the most valuable. Early in the project, you'll also want to focus on the stories that will lead to the best feedback--either stakeholder/user feedback or technical feedback. So, stories at the top of your stack-ranked backlog should be small and well-defined, and stories at the bottom will be larger and more vague. As a result, you are constantly evolving the backlog, and getting input from stakeholders on a regular basis.
How do you handle "change control" when new stories are created mid-stream and you have a deadline to hit?
Ronica Roth: There is no change control in Agile. Short iterations are your change control. At every iteration boundary, the PO can change priorities. Within the iteration, the stories cannot change. That said, during an iteration the story might grow. When that happens, the team and PO have to work together to decide what to do: Build the story anyway and drop some other story that won't get done; break off the expanded functionality and make it a new story; or otherwise adjust. We can always put stories on the backlog. The PO owns deciding when to call for releases, when to de-prioritize less-valuable work.
Should decisions made during conversations between the team and the product owner be captured in the story as acceptance criteria?
Ronica Roth: Yes, that's usually exactly where it's captured. It could also simply be captured as a note.
How are conversations documented? What is the forum for these conversations?
Ronica Roth: Conversations happen all the time. The PO, ScrumMaster, team, and stakeholders might discuss stories during a backlog grooming session. The PO, SM, and team might discuss stories as they are sized during release, or mid-range, planning. And the stories as discussed again when the team creates their sprint plan. The results of all those conversations might: Refined stories, stories broken down into smaller stories, and Acceptance Criteria. We might also simply add notes to the story to remember our conversation. We might also capture stories as test cases, tasks, designs, pictures, prototypes.
Can you talk about Engineering stories (e.g. "We need to refactor to make our lives easier before moving on.")
Ronica Roth: Even "engineering" stories should be written in terms of value to a customer or user. Such as, "So we can provide more features faster..." Or, "As a user, I want a stable system..." Even "engineering" stories must be owned by the PO. So, it's important to be able to describe the value in a way that helps the PO understand how to rank it. And, part of pulling quality forward is figuring out how to prevent needing those stories. Can we make refactoring a practice we do all the time (always leaving code better than we found it)? Can we do more unit testing? Can we do the "engineering" work while also delivering a feature? Should we do a little more design every sprint?
How to handle strictly functional items - like creating a new installation based on a new tool? Or investigate a new technology - like the optical toast sensor.
Ronica Roth: XP brings us the concept of the "spike". A story to investigate a new technology. The idea is to timebox our investigation--to make sure we work quickly toward a solution, or a direction, or a determination that it's too expensive. We want to get the feedback, and present the team/PO options. I would call few things as "strictly functional". Most things can be tied to the value it brings a user or customer.
Where do you do the detailed documentation for a User Story?
Ronica Roth: Wherever works for the team. In Rally, there is plenty of room in a story to add notes. You can link to external documents like data dictionaries, or wireframes. YOu can manage a wiki with pictures of whiteboard drawings, or with other detail. I challenge to write as little as possible (working software over comprehensive documentation) and keep inspecting and adapting on whether you are writing enough or too much. Any document that's never read is waste. Any conversation that gets forgotten should have been captured. :)
Do you manage bugs in the same product backlog as a user story? do they have the same criteria to be prioritized or just allow a % of the iteration for bug solving?
Eric Willeke: Yes, they are in the same backlog and are prioritized among the user stories by the product owner.
How do you determine user story vs. task? Do you have technical stories that are handled as tasks in sprint backlog rather than product backlog?
Eric Willeke: I draw the difference as this: The story is the team's commitment to the product owner. The tasks are the team's notes on how it will meet that commitment.
Technical debt and bug issues... how are these represented as user stories? They are definelty part of the backlog and should be prioritized with the other stories. Is the story format mutalble?
Eric Willeke: Specific defects aren't always represented in story format and are instead captured as "defects." Technical debt should be captured in terms of how fixing it is valuable to the users where ever possible, but it can also be captured just like any other defect.
What do you do if the User Story is not clear and it creates problem for the team? What is the best way to handle such situation?
Eric Willeke: Ideally, the team identifies this before accepting the story at the beginning of the iteration. The team then works with the product owner to get the story to where it's clear and ready to go. If the lack of clarity was unexpected and the team accepts it, the team should work with the product owner to resolve the specific issue as best as possible, and then ensure that the root cause is explored during the retrospective.
Can or should you rely on user stories as complete documentation?
Eric Willeke: This depends what you mean by "complete." If you follow the card/conversation/confirmation model, then the card supplies the information needed to start implementation, but is not intended to stand on its own in absence of that conversation.
Should each user story have a corresponding task? If not, does it indicate that the user story is way too detailed?
Eric Willeke: Different teams do this differently. Some teams fully task out each story to a number of tasks during sprint planning, others allow the development team to do the task-level details as needed when they "pick up" the story.
Do you have templates for creating good user stories with examples of the entire process of creating a user story anyone can use?
Themes and Epics can take a long time to break down to small enough user stories to process in a sprint. After the first sprint starts, is there a on going process with the product owner and team to breakdown the Themes and Epics to smaller components?
Eric Willeke: Yes, the product owner is continually working with the team to appropriately decompose the work ahead of the team's development efforts.
There may be user stories that create a sequence of events and decisions that need to occur in a specific order. Do you still decompose the user story into individual requirements (as shown so far) or do you turn user stories into models/diagrams?
Eric Willeke: There are a number of ways to split the sequence into multiple stories. The goal is to get the pieces small enough to be meaningful and individually implementable without losing perspective to the overall effort.
Do many folks actually use 'cards' to capture user stories? If not, are there good tools out there? How do you plan tasks based on these prioritized user stories - a set of cards?
Eric Willeke: Yes, a number of teams use cards to work with the stories and plan, then capture them in an electronic tool. if you're using a physical task board, yes, more cards would be used to represent each task.
What about Engineering / Infrastructure stories?
Eric Willeke: We typically recommend that engineering and infrastructure stories are captured in the standard story format and represented in terms of the expected value of to the user. For example: As a web user, I wish to have a response in under .5 seconds when placing an order so that I don't worry about my credit card information being at risk.
What is the difference between 'enough' info for a user story and a true gap in requirements (as outlined in a user story)?
Eric Willeke: Bob will later cover the ideas of "Card / Conversation / Confirmation". The goal is not to capture all of the information required in a user story, but instead to capture the intent and promise to hold a conversation about the required functionality. This allows details that are learned between the conception of the story and the implementation to be captured through that intentional conversation process.
I work with a lot of technical projects where the users are systems. We also tend to have a great amount of the system architecture/design define prior to the user story definition. We struggle with writing true user stories in those situations.
Eric Willeke: Julie, this is a common challenge in systems integration organizations, and teams typically find it valuable to represent the consumers of their services as personas, possibly breaking different types of consumption as different persona types. For example, consider consumers of Twitter's search API vs. their streaming API, and large consumers vs. individuals using something like TweetDeck.
If a story represents a feature, and that feature will run on a variety of paltforms and be implemented by different teams on those different platforms, how do you go light, but ensure enough detial that the behavior of the featue consistent across teams?
Mark Kilby: This sounds like an epic (story that can't be completed in one sprint) that will be split into smaller stories. Each of those smaller stories may be per platform.
In larger organizations (such as The Home Depot), do you believe in separating the IT and Business stories?
Mark Kilby: You can have IT and Business stories in the same backlog. Business stories take priority
How you manage Technical User Stories?
Mark Kilby: Technical user stories are somewhat of an agile anti-pattern. If all of your stakeholders don't understand some stories on the backlog, you may need to rewrite the story in business terms and make the business value clear. I've rewritten many tech stories this way as a coach.
How do you recommend getting the team to create "small" user stories
Mark Kilby: I find story points the best way for the team to quickly consider complexity, effort and risk and let the product owner know if they can build that story in the sprint. Points with a historical measure of velocity (points of completed stories accepted by product owner each sprint) are complimentary practices
How do you know when you have enough documented in your story to begin development without causing too much re-work?
Mark Kilby: Re-work can have a number of causes. One of the most common I have found as a coach is misunderstood requirements. Best way to verify the "detail" is to choose the shortest sprint your team and stakeholders can accommodate to provide feedback on implementation versus the business needs.
Can you speak to how to write user stories for Data Ware house projects and/or R&D efforts? These are areas that we've had challenges creating verticle slices.
Mark Kilby: Not a short answer. We have coaches doing this work now. Happy to discuss via a Team Tuneup.
How do you keep the user story at a business level when developers and architects are in the meeting together? We tend to drift into design.
Mark Kilby: Your scrummaster/coach should help the team come up with working agreements on minimal design discussions. Techniques like planning poker help to keep conversations brief also.
What do you use to document a user story. Is is a scaled down version of a use case or something else?
Mark Kilby: A user story is actually more than a use case. Bob will talk about the acceptance criteria which captures much of the same details of the use case. What is unique is the WHY, which describes the business value of the story to help the product owner prioritize when the story should be built.
In my experience, some teams use "stories" and some use "use cases"? Are you encouraging using both?
Mark Kilby: If you are referring to agile teams, we recommend that teams with similar groups of stakeholders use a consistent way to describe requirements in business terms and expressing the business value. User stories tend to be better for this.
Would user stories ever be resurrected or re-evaluated after production release of the features?
Ronica Roth: I wouldn't think of it that way. I think of it more that if upon release we get feedback that a feature wasn't "right" or that we didn't implement it quite right, then we would put new stories on the backlog for the new/changed functionality. Then, in a release retrospective or other retrospective, we would want to make sure we learn: How could we have gotten that right in the first place? Or, are we excited that we were able to learn quickly?
If developers have to perform extensive research to determine estimate, do you create a user story for determining the estimate?
Ronica Roth: Yes. That's called a research spike, and you timebox it. The deliverable is the estimate.
Can you elaborate on the difference between user stories and use cases?
Rob Pinna: Use cases are often too large to schedule in an iteration therefore you just need to break them down into their scenarios. As a use-case scenario provides end-end value to the user it provides a very natural form of decomposition. The use-case brief description is quite similar to the story format and the use-case flow of events is similar to a story's acceptance criteria (see http://dannorth.net/whats-in-a-story) so there is definitely a migration path. What use-case authors will find different though is that agile teams will defer commitment on the acceptance criteria (use-case flow of events) until they know for sure that the story will be delivered.
How important is it to have the business/functional processes well defined and documented before starting the user stories (especially when it is a new process to the company)?
Ronica Roth: I would ask it a different way: How could early feedback help us understand the process we are supporting and to develop a better system? You may want to build the who process broad but shallow, to make sure that you've got it right. In my experience, showing people the software helps clarify the process. Also in my experience, some elements of the process are clear and you can begin coding, even other parts are being developed. Start sooner, and rely on feedback.
Requirements were treated as the 'source of truth' after develeopment was complete to review 'what was built.' There were issues with this, but regardless, user stories dont seem to fit this need. What should be used? Test cases, design doc, etc?
Ronica Roth: Some orgs use user stories. Some create lightweight design docs. Some use test plans. Others use the code itself: That is, code is written so clearly that it is self-documenting. I recommend using the lightest thing that will work. Ask the people who will use this documentation, try it, then verify that it was useful. Inspect and adapt. In my last PO role, at an investment company, we used the stories test cases (in Rally) to track what we built; we taught our auditors to understand that documentation.
User Stories and PRD's/MRD's and Documentation
We have something called Requirement Traceblity Matrix so that FSDs and TDs could trace back to Business Requirement. How do we tackle that in User Story?
Ronica Roth: This is common in regulated environments. We're doing a lot of work in this area. Because user stories are ideally vertical slices of functionality, it is often even easier to trace stories to business requirements. Because stories are written in clear, plain language, you can often write business requirements as epic user stories, and then break those down into smaller stories (maintaining the relationship to the parent epic), and thus maintaining traceability.
The PRD is good document to have to communicate around the organization. How can you leverage the backlog/user stories to get a similar sort of communication tool?
Ronica Roth: I think it's important to have a hierarchical backlog with features and epics that describe high-level functionality. They can be written as user stories (with a WHAT, WHO and WHY) or not. But the key is that they'll describe at higher-level what you'll be delivering. Share that level in the organization. Then, those get broken down into smaller stories, which teams deliver. IDeally, reporting of those stories rolls up to the larger epics, so you're always giving real-time status and updates. I also think story maps make a great way to depict what you're delivering and how deep you're going in each area in the system.
Having some content in the BRD such as "As-Is" and "To-Be" information with workflows and actors are helpful...how does this translate when working in agile?
Eric Willeke: Agile does not exclude organizations from any information they find valuable. We would typically translate business processes with as-is and to-be using some form of Story Mapping.
How does one handle a request from a major project funder/customer who wants a detailed plan for an entire year at a time (in a large multi year development project)?
Eric Willeke: Manage the level of detail in that detailed plan. Detailed staffing levels are reasonable, and a prioritized backlog of epics to go with it. The funder and customers should be invited to the (probably) quarterly release planning events. Do not attempt to capture a full year's worth of detailed stories... that should be focused as 2-3 sprints ahead as Bob just shared.
How do you avoid a requirements document when your company is outsourcing the project to a team out of the country (challanges in location, language,...)
Mark Kilby: If the development team is outsourced offshore, this may be difficult if the offshore site does not utilize agile. If the outsourced team is within your office offshore, it will likely be easier.
How does Agile operate in government contracts where large requirements documents are part of the contract?
Mark Kilby: There are more government organizations starting to embrace agile and provide more flexible contracts. When they see how agile allows them to respond better to constituents and changing laws and regulations, the contract officer will find a way to make it work.
Big requirements documents can be good for some project teams. It depends on the situation?
Mark Kilby: I have often found that big requirements documents are (a) never read cover to cover, (b) require an enormous amount of time to produce an maintain, and (c) is not the final product. With that being said, I still have some LARGE agile teams that use some lightweight documentation to help explain the structure of the backlog. The details are in the backlog itself which can be very detailed and long. So we capture the same information, but in a different way and at a different pace and only when those details will be needed by the team. For instance, I've seen backlogs in the Rally tool with thousands of stories with very clear structure.
What tools do you recommend to store and track user stories?
Ronica Roth: As both a PO and an Agile Coach here at Rally, I can't recommend the Rally ALM product enough. It was built to support Agile from the ground up. It's a very effective tool for managing your product backlog, from high-level features and epics, all the way to tasks.
Where can we find a good real life IT example on how User Stories go from high level Voice or the Customer to very specific and decomposed into detailed requirements ready for the dev team to build (code) a sprint prototype?
Ronica Roth: I have a good example or two, which I plan to add to add to our user stories toolkit in the next couple of days. Please check back.
How do you guide the requirements to avoid subjective analysis. You say, "limit the requirements to those that add value." How do you balance Agile with objective metrics for "business value?
Ronica Roth: Agile makes metrics for "business value" more important than ever. In my experience, though, many organizations are better at measuring cost (how big is it, how long will it take) than value. Because measuring cost is easier. It's worth it to find ways to measure value. That said, subjective analysis might be better than no analysis. And objective analysis is better than subjective analysis. Always work to understand value better. Agile projects are often "faster" not just because we work faster but because we don't spend time of items of less value.
Can the Rally system allows relating user stories (requirements) from various projects (i.e.; allow true application requirements management)?
Ronica Roth: Yes, can do that in variety of ways. One might be through the project hierarchy, where the top-level project has high-level requirements, and children are associated to child teams. YOu also might use tagging to indicate related backlog items across teams and projects.
Could you menntion which are the difference between Velocity and Capacity pls?
Ronica Roth: Velocity is a historical measure of the story points the team has delivered per iteration. Capacity is the amount of hours the team has available in a given iteration, considering vacation, work that we don't plan in the iteration (such as production support or answering emails), and commitments outside the team.
How do you like to handle dependent stories (given the goal is to make them independent, but not always possible as you decompose them)
Ronica Roth: We try to minimize dependencies, but eventually they'll exist. Within one team, we can often handle dependencies through ranking. Across teams, we'll want a more sophisticated way to track dependencies. In Rally, we simply mark stories as predecessors or successors, and then you can run dependency reports via the app catalog. In planning, you'll want teams to pay attention to dependencies and probably plan dependent stories for idfferent iterations.
What is the best way to handle projects that go across teams?
Ronica Roth: When we scale Agile to the multi-team program level, we need to add structures to help us with the added coordination. From a backlog perspective, we might create Epics or Features at the program level, and break those down into stories that go to teams. Ideally, we can track progress at the program level (Feature A has been broken down into 10 stories; 5 are done; 2 are scheduled; 3 not yet scheduled). The POs for each team will need to coordinate regularly, to ensure the work of the teams lead to value at release time. They might be organized by a Chief Product Owner who ensures everyone stays on the same page and heads toward the same vision.
How often a feature is used says nothing about how important that feature is to the overall product or how important it is to 20% of customers that provide 80% of the business.
Mark Kilby: Correct! So a backlog of user stories may be ranked using a number of different criteria such as ROI, importance to key stakeholder, or criticality based on other factors
You actually get requirements? I wish we did.
Mark Kilby: Actually, user stories can be submitted by the team as well. When I've not received requirements, I've encouraged the team to submit outrageous stories. When the stakeholders push back, then I get the real requirements.
Using Agile, are the user stories shared with the stakeholders of the requirements to get concensus?
Mark Kilby: As often as possible. Making the backlog of stories accessible all the time is key
2) If the "Team" really decides what they can complete in a Sprint, how and who ensures maximum productivity?
Mark Kilby: Team with ScrumMaster/Coach primarily.
An iPad app seems to be a nicely contained world. Has the Citi speaker done something substantially larger using an Agile approach? If not, this does seem like a "sweet spot" success description.
Mark Kilby: I don't know all of Geoff's background, but as an agile coach, I've used these techniques on a wide variety of systems including ERP, insurance processing, even hybrid hardware and software projects
Are stories tied into a larger framework vision / roadmap?
Mark Kilby: Yes, Bob will mention 5 levels of planning
How do the stakeholders or any team member get a sense of what the application does as a whole? It seems as though User Stories provide a more "fractured" vision of the product rather than the overall target of the application.
Mark Kilby: A few ways to do this. Team should be reporting on how user stories roll up to features through their tracking tool and in the sprint review meeting. As they demo functionality for a user story, they need to describe what piece of the overall functionality represented and what are some related stories completed and those to come. If the team cannot do this, the product owner should be able to
In an agile project, how do you work when you have both IT and Business Product Owners? Which owner has the lead or does it require complete collaboration?
Mark Kilby: As an agile coach, I would recommend having one PO who can represent both interests in a balanced way.
Sharing stories with outside partners. Is there a rule of thumb to how to handle this? Where company A is functionally supporting the product for company B.
Mark Kilby: Typically better to flow some of the requirements to Company A and some to Company B and track the dependencies via synchronized sprints and releases. Having the same tracking tool for both companies is important also. Rally was designed for scenarios like this.
We use DOORs to capture user requirements that are provided to engineering for acceptance and elaboration. When would the user stories get started?
Mark Kilby: User stories start as soon as a product owner is identified to manage the backlog of stories. Elaboration happens sprint to sprint.
Who creates the testable scenarios?
Mark Kilby: The team creates these test scenarios which should consist of a QA person as well as BA, Developer and another other staff needed with skills to produce a final slice of the product.
The confirmation looks and smell as what many of us call a Use Case. I don't see a difference other than semantics
Mark Kilby: Confirmation captures much of the detail of a use case. Difference is it can evolve through release planning and sprint planning. Another difference is the WHY of the user story
Should Rally be used as a project management tool?
Mark Kilby: that is one of the primary functions of the Rally tool
I work with multiple engineers around the world, many of whom are from China and Singapore and require very, very, very explicit requirements. (Must specify the behavior both when checking and unchecking a checkbox.) How much detail, and what kind is OK?
Mark Kilby: In working as an agile coach in such teams, the request for specific requirements usually indicate that the offshore folks may not have an understanding of the business and the business may not be accounting for the time zone and cultural differences of the offshore team members. Get to know them and help them get to know your business.
How do you do a cost-benifit analysis with stories?
Mark Kilby: Look at Mike Cohn's book on Agile Estimating and Planning and another book, Software by Numbers
Scope typically is not negotiable unless schedule is negotiable. How do you balance these in the user stories and in the product backlog?
Mark Kilby: The balance happens between stories, backlogs AND sprints. So the schedule and scope is always re-negotiated at the beginning of a new sprint based on the results of the last sprint.
How can the documentation and testing processes be adopted in the Scrum approach?
Mark Kilby: You want to hear our next webinar on Definiton of Done.
How do we handle working with a offshore team that is on waterfall while we are on Agile?
Mark Kilby: Try to align on releases and minimize dependencies between onshore and offshore teams. Use sprint reviews to keep them informed and ask them for status at same frequency.
How would you recommend to engage business stakeholder and clients (aka The General) in the transformation from contract commitment up front to collaboration along the path?
Mark Kilby: You might be interested in our Agile Rollout Planning.
Is agile only aplicable for TI Software Projects?
Eric Willeke: Agile can be used in a number of environments, although it has definitely been primarily based out of software. Take a look at http://pm.stackexchange.com/questions/1470/agile-methodologies-such-as-scrum-in-non-software-development-projects for more information on other areas.
How does agile work within highly regulated environments such as FDA?
Eric Willeke: Agile works quite effectively in what Rally calls "high-trace" environments. Check out the section "Agile Tooling for High Assurance Software Development" in http://www.rallydev.com/agileblog/series/#Agiletooling.
Where does Engineering Design or Architecture find its place in Agile development?
Eric Willeke: The details of the architecture will emerge in the same way that the details of the stories will emerge as they are decomposed from high-level ideas into "ready to implement" user stories. A team should focus on the balance of having enough implemented architecture for supporting effective development and scaling against the need to retain options for taking the architecture in the right direction later.
Agile recommends features of higher "business value" first. What is the definition of "business value" and what are its components?
Eric Willeke: Business value can have a number of different aspects and depend entirely on your business. For one perspective, take a look at http://en.wikipedia.org/wiki/Kano_analysis.
How successful are user stories in an organization where deveolopers have little subject matter expertise?
Eric Willeke: The long term goal is to help the developers grow that domain knowledge. In the meantime, the product owner should be spending enough time on the conversations to ensure the understanding is gained in time for implementation. Stories still work regardless.
How do we address long term documentation requirement?
Eric Willeke: It depends on which forms of documentation are required, and when it will be needed. If you're talking about user help, I strive to implement it throughout as a portion of each user story. The high-trace aspects of FDA or FAA are often handled through the use of a tool like Rally to capture the design history as well as supporting the needs of the development team to plan and execute the project.
How long should backlog grooming sessions be, and how frequently should they be held? Basically, how much preparation time should scrum teams be spending during a sprint preparing for the next sprint?
Eric Willeke: The details are dependent on the organization, but I find myself recommending the same amount of time as is spent on sprint planning in a set meeting halfway through the sprint.
Should regression testing during every sprint when there are multiple projects that are introducing new logic into a test region?
Eric Willeke: The long term goal should be for the regression being fully automated where possible, allowing them to be run every night. As you work towards that goal, do what you can to ensure that the most valuable tests are executed in ways allowing the work to be trusted.
How do you report % of completion at a project level?
Eric Willeke: Agile projects typically report "what is actually done" in real terms. This can be compared at a release level using a release burndown, or at a product level by mapping progress against a minimum viable increment for the product as a whole.
I've seen some blogs asserting that some requirements and systems are too complex to be developed through user stories. How do you feel about this vs. the concept of emergent design?
Eric Willeke: Stories are never meant to stand entirely on their own, and the conversation may contain a lot of supporting material for highly complex environments. The team should also focus on managing abstractions effectively as described here using the DEEP model.
The traditional "project" has a start and an end. How does this view get changed (or does it) in the agile release / product backlog cycle which could keep going on and on with no end in sight (can always improve the product and add more features)?
Eric Willeke: An "agile project" is similar in that it has a specific set of goals to achieve. An "agile product" may be focused on continual development until more valuable products emerge to focus the team on building.