Q: At what point does an agile user story become a task and what is the best way to balance informing the development team of the intended functionality versus telling the development team how to complete the functionality?
The user story is broken down into multiple tasks, typically during the Sprint Planning Meeting, but increasingly I see this happening with the team on a per Backlog Item basis. If we are ever in a situation were we are telling the development team how to complete the functionality that might indicate that we are having some issues with roles. Based on what I have been seeing lately I would wager that this question is asked because a Product Owner is only part time, and they are also a Dev Lead/Architect/CEO/Pizza Delivery Man.
Keep in mind that User Stories are there to give the team a full understanding about what the needs of the User are. This is why User Stories need to be so explicit about who this thing is being built for, and why they need it. This can allow a team to consider methods of meeting those needs without being told how to. The tasks are a record of what the team decides needs to be done to meet those needs.
An example I use to explain Epic Breakdown, User Stories, and feature delivery is this:
“As a Hungry Man I want Eggs Benedict because I really love Hollandaise sauce.”
This is a very basic Story (or Epic). It needs to be broken down into a 5 user Tasks (these could be user stories also, but for this example we will say they are tasks):
1) Make English Muffin
2) Cut Ham
3) Cook Eggs over easy
4) Make Hollandaise Sauce
5) Put it all on a Plate in order
As a full feature (Eggs Benedict) all of these elements need to come together in that order. The point I want to make about user stories is that changing the story just slightly changes how we would deliver the feature (Eggs Benedict) completely.
“As a Starving Man I want Eggs Benedict because I really love Hollandaise sauce.”
Suddenly we have a greater understanding of what the user’s needs are. He may love Hollandaise sauce, but does he need it? What if the wait for Eggs Benedict kills him? Instead our task breakdown would look like this:
1) Cut Ham
2) Put it on a Plate.
Because the team understands what needs to be delivered, without being told how it needs to be delivered, they can meet the needs of the user more readily. A good user story presented to a team of professionals working together will result in a better set of tasks for delivering on the needs of the User then any one individual creating tasks and assigning them can.
Q: On the Release Burnup slide, the backlog effort seems to go down in the second or third sprint; How is this possible (ending a spring with a negative story points achieved)? Thanks
Very observant of you, I use this specific report just to see how many people catch that as it is a good way for me to gauge understanding of the report.
This was a situation were the product owner accidentally removed completed work from a previous sprint, then later added it back in. This report shows that as it is a historical record that will track everything that occurs. That dip in the sprints shouldn’t be something that ever occurs for the majority of people.
For reference on this question, here is the report:
Q: On the Product Backlog demo slide, each item has an ROI; How do you evaluate this for the backlog item?
In ScrumWorks the ROI value is a calculation based on a value input to indicate the Benefit of Inclusion in the Product. Another value that indicates the Penalty of Omission from the product. These two values are added together to give us a Business Weight. The Release Business Value is calculated by comparing the Business Weight of this item to the Business Weight of all other items in this particular Release (a Release may indicate a real release, a period of time, or any other block of work we like).
The ROI is calculated by taking this Release Business Value and factoring in the Effort Estimate, or difficulty of this item in comparison to other items within the Release.
Because different groups can put in the Benefit, Penalty, and of course Effort we can calculate ROI based on the input from 3 distinct groups. For more information I would suggest looking in our documentation on Earned Business Value: http://www.danube.com/docs/scrumworks/pro/latest/userguide.html#earnedbusinessvalue
Q: how do you avoid testing on a “moving target”?
Nearly all software is a moving target, so the real question is how do we get value from testing this moving target? This is where practices like Test Driving Development (TDD as described in Extreme Programming), Continuous Integration, and Continuous Deployment come into play. A relentless focus on quality means that we never create anything without an automated test being created as concurrently as possible to it. It means that we accept that ideas like “Testing Quality In” and only testing at the end are a relic of assembly line thinking that just doesn’t apply to the majority of software development.
Test isn’t something that just happens at the end (although there’s nothing saying that it can’t be there also). Test happens all the time, it is a continual process precisely because we are dealing with a moving target.
Q: Our team struggled with relative estimation because we can agree on what is small vs large. What’s the best way to resolve this?
Based on how the question was phrased I would guess that you are using something like T Shirt sizes, i.e. Small, Medium, Large, etc? If that is the case then the answer may be to go with a slightly more fine grained scale, like the Fibonacci Sequence. T Shirt sizes are a good way to learn estimation, but in actual practice they are not applicable to every project. This could be the root of the problem
To actually answer the question, it sounds to me like the team might need to get a better foundation on what Small vs Small means before they start in on Small vs Large. When you have a good idea of what the smallest thing you could possibly have on your backlog is the question just becomes: “Is this 5 smalls?”. An experienced ScrumMaster can be invaluable in situations like this when they can take the conversation back onto the rails by asking a question as simple as that. Additionally they can help to overcome this problem with the use of a tool like Planning Poker, which is of particular use to a ScrumMaster by cutting conversation that is looping short and forcing the team to come away from talking into circles and back into valuable conversation.
Q: Is the User Stories used as functional spec?
Could be yes. More likely a functional spec is a series of User Stories, or a user story and some additional backlog items. Keep in mind that a backlog item can be more then a user story. Depending on what they are you might have a backlog that mixes actual functional specs with user stories, defects, research, etc. It depends on the project, how small the functional specs are, how well they are understood, and whether or not they deliver business value.
An all too common problem I am running into is this idea that a backlog consists of only user stories, something that couldn’t be further from the truth.
Q: In Waterfall, functional/technical specs are required, what is the best way to incorporate them for Scrum? Our QA team refuses to start anything without any functional specs.
Functional/Technical Specs are still required in Scrum, the only difference is that we admit that they are likely to change as time moves forward and as we get into actually developing the product. With Scrum we have a framework for producing working code even with out a full set of functional specs in place. You need enough to get started, and enough to have a vision behind what is being built, but many of the details are filled in as you go.
The second part of the question concerns me more then the first part. The idea that you have QA team is problematic for Scrum, and that they can refuse to start work seems like it may be problematic from a business standpoint. I can only make assumptions when answering some of these questions, so here I have to assume that we are talking about a QA silo in your organization.
For Agile to be successful your organization will need to break down that (and likely other) silos and incorporate your QA people into your Scrum teams directly. One major positive for many good QA people in this arrangement is that they are involved from day 1 in testing, and even in helping to define what ultimately goes into the functional spec. This is a major shift for many long time QA people, but they do need to understand that their expertise is absolutely essential for making agile work. The experience and mindset that a solid tester brings to a Scrum team is a major component to Scrum’s success.
Q: How do you define risk, Is it technical or business risk.
If this question is in relation to managing Risk in Scrum using the backlog? The answer is both. The Product Owner is constantly gauging all forms or risk and factoring that into how they prioritize the backlog. This is actually one of the key value points of the backlog, this idea that we can take every possible data point and factor that into our decisions regarding how we prioritize what we deliver. Of course this is a time consuming and difficult job to do right, which is why I stress time and again the importance of Product Ownership, and that a Product Owner who has other jobs and duties likely cannot do the job that is needed. I see a lack of solid Product Ownership as the single biggest problem plaguing Agile adoption today.
If this question was in relation to the description of the ROI feature in ScrumWorks the answer is: either. As an organization you can decide what risk means, Scrumworks will work no matter what you choose as long as you are consistent.
Q: Can you give some examples of user stories
I have a very basic example a few answers up of Eggs Benedict, but I suspect you are looking for a bit more then that. Luckily I can direct you to another blog entry all about this topic.
Q: On the Programme view, if the teams use diffent Story Point sizing, presumably they’re working from separate Product Backlogs. Can you have multiple teams working from 1 Backlog? If so, won’t they have to agree on what (for example) a 5 SP story feels like?
In the Program View you are looking at teams that have different backlogs, the scale they estimate on can be whatever they choose. The Program function was specifically built to cope with this.
You are correct in that if you have multiple teams working from 1 backlog they will likely have to agree on some unified scale. You could use Themes to filter on work estimated by one team or the other, but if the scale was very different then reporting would be more difficult for the Product Owner. If you had two teams that agreed to use (for example) the Fibonacci sequence it would work out just fine in ScrumWorks.
In terms of the teams agreeing on what 5 Story Points means it wouldn’t be very important assuming you are having the teams estimate the work that they are going to do. You simply want to make sure that you attempt to identify a sprint ahead of time that this block of work will likely be for Team A, and another for Team B. This type of thing can be tracked easily using Themes, and if a piece of work that we thought one team was going to do ends up going to another team then it can just be re-estimated.
Keep in mind that averages are what matter when it comes to reporting. Even if the averages are “flawed” as long as we are as consistent as possible we can still get valuable forecasting information.