My team recently switched to using Team Foundation Server to support Agile. We decided to run sprints every two weeks. We plan to write the stories so, ideally, they can be finished at the end of each two week sprint. We find that some stories have tasks (usually research or learning someone elses API) that will take much longer than our sprint duration. Does TFS have some way to record effort into such tasks without making it look like the stories should be completed at the end of the current sprint? Failing TFS, is there some 'Agile' way of handling these items?
I suggest you figure out how to break down the work into smaller pieces. My rule of thumb is a Task should be more than an hour and less than a day.
Alternatively, you can still create Tasks against User Stories that aren't assigned to a Sprint if you choose to. Although that doesn't feel very Agile to me.
Related
Want to build a report showing each team member's percentage contribution per a completed Sprint.
We break up the work in Tasks and assign a Remaining Work value to indicate the time needed. The problem then is that remaining value is clear or decreased as the sprint progresses.
Have been looking for a way to find the original remaining value, so I can use it for reporting post the sprint. All in an effort to try and build a relation between originally set Effort and Actual hours.
Any assistance would be appreciated.
First I have to say this, as a Professional Scrum Trainer with Scrum.org, we highly discourage the breakdown of effort to the individual team member as part of standard reporting. Where scrum is concerned, the individual contribution is of little consequence outside of the team context, and inside of the team we feel that team members should be able to openly discuss the perceived value added by other team members as part of their Sprint Retrospective.
Secondly, because TFS can't register multiple users being assigned to a task, nor support the trackign of hours spent by multiple team members on the same task, your report will either be incomplete at best, cause additional administration overhead in most cases and may even cause team members to not work together at worst.
That said...
TFS tracks all assigned and saved values for work item fields. Using the API it's easy to iterate through the work items and retrieve their previous Revisions. As an alternative, the API offers asof work item queries which allow you to track what the values of a workitem were on a specific date. This information is also store in the TFS datawarehouse, if you are using it, aggregated at the daily level.
But if you need accurate tracking of time spent, the only reliable way is to add the Completed Work field to your work item type definition:
Completed Work
The amount of work that has been spent implementing a task. You can specify work in hours or in days. There are no inherent time units associated with this field.
Reference name=Microsoft.VSTS.Scheduling.CompletedWork, Data type=Double
Task, Bug
This is required to cover cases where the original estimate was lower than the actual time spent, remaining work would in that case remain the same, or even increase, while a team member had spent time on that item. without also tracking CompletedWork, this data is lost.
The Agile and CMMI template use this field by default. The Scrum template doesn't, you can guess why based on my initial cautions.
I will be using TFS 2012 and I am confused as to how to setup work items for one job where there are dependencies to the steps needed to get the job completed. For example, if the job first needs to get feedback from the end user, then a developer needs to build the base classes. After the base class work is completed then another developer needs to build the UI components. After the UI is completed then the tester needs to test the work. This job requires multiple people, including more than one developer. Each step cannot be started until the prior step is done. Should all of these steps be different work items or all in one work item? If multiple work items, how do you have the work item show as ready to work on for the next person when the prior work item is completed? If only one work item, then how do you handle the steps for multiple developers? This is one example. There could be the case where we have five developers all dependent upon each other before they can start their own work.
It sounds like you're trying to fit TFS into a formal waterfall process. It probably isn't going to be a good fit in terms of creating Gantt charts for you. In TFS you can use the hierarchy of user stories and tasks to accomplish half of what you want. For the other half you can create the appropriate link type between the tasks.
However, TFS isn't going to give you a Gantt chart like view for them, it isn't designed that way. If you really want to manage projects in this fashion, I'd look at integrating TFS with MS Project and/or Project Server.
As an aside, I would strongly consider just having those people talk to each other rather than relying on a tool.
As long as your performing an agile process your on the right track. Sprints should be based on PBI deployment, not completed tasks. If you find yourself pushing a PBI across multiple sprints, you may want to break-up your PBI. It is better to do this than keep wondering if your team is getting things done, since a group of tasks are moving into a new sprint. Getting a PBI to completed at the end of a sprint should be a key goal for an agile team.
Assign all the tasks needed to complete the PBI. Tasks should be created by the team together. This will help decide how to break down the tasks. I would break down the tasks mentioned into independent tasks based on functional groupings (UI, Business Model, ect). The art of this is to not break them down too much. The team will decide this for themselves. (remember to keep agile and let the team make short-term mistakes if it will help long-term: estimation, scope, quality, ect.
Assign QA tasks with unique names for each PBI. Don't use QA for the task name, it can become difficult to prioritize on the Board view. If you have a test team, let them create there qa tasks. Agile is agile (the team is the team).
The other main key point I learned was don't move on to tasks until the PBI has been planned completely, don't move on to sprinting until the tasks have been planned completely. This will help ensure that once your are sprinting, your not making decisions for that sprint in the middle of the sprint.
I hope this gives you some pointers.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We are in the process of starting to use Scrum (in combination with TFS 2010 and the MS Scrum template) in our company. Since none of us have any experience there are still some questions to be answered.
Since our Product Manager and Scrum Master are non-technical people it would mean that we, the Developers will be part of the meetings that split up the feature requests in small Product Backlog Items. It is my belief that we can do this on our "planning poker" meetings to discuss the feature. But how is this planned in? Let's say that we get a new feature request in the middle of our sprint. (Our sprint will be 80/20 timed.) Should we keep this also into account when planning our sprint, or would it simply mean that the time we spend in that meeting must result in items moved back onto the Product Backlog.
We know we should split a feature up into as many PBIs as we can (and of course, that makes sense) and that a single PBI should not exceed the length of one sprint. That also makes sense. But where should we draw the line? For example, our application communicates with several USB devices. The feature request is that we should communicate with a new device. Implementing this is a 2 part job:
a) add the communication with the device to our USB library;
b) add UI support for this device
Should we split this up into two separate PBIs, or is this one PBI of which we should create multiple tasks?
On a side-note: when a PBI has been added, should we create a task for each PBI when we start implementing it? As far as I see in TFS we cannot set remaining work hours on a PBI. So my initial idea was to create a task for each PBI. But I know some colleagues will find it "a lot of work" to create a task for a PBI that only has one task. How should we handle this?
In Scrum, it is the PO's responsibility to break the features into small-enough user stories. That being said, there's nothing wrong with the PO getting help from the team (or anyone else for that matter) in splitting them. The planning poker session might be a good place to fine-tune the split, due to the team's input on the complexity of each story, but the PO should have a sense of how to split the stories beforehand.
The planning session should take roughly half a day. Definitely not a significant portion of each sprint. Regardless though, the remaining hours in the sprint (e.g. 90-5=85, in a two week sprint) should be the amount of time that the team has to fill with the stories' tasks. Of course, no matter how much time is left in the sprint, any stories that the team can't commit to should be returned to the product backlog; they won't be done in this sprint.
The stories should be sized appropriately, i.e. can be completed in a single sprint. Personally, I prefer to size stories so that a few stories can be completed by the team in one sprint. A good rule of thumb (but not a hard rule, by any means) is to stop splitting your stories when you reach the point that they can be released by the team in 3-5 days.
Though you didn't ask how to split your features and split them along the lines of Core capability, entry barriers, key differentiators, and nice-to-haves.
Regarding Breaking the stories into tasks: You should have at least one task per story. Stories define what needs to be done; Tasks define how. You should probably have at least one task per participating component of the system, as well as one task per actionable item in your definition of **done. If you have only one task, then you probably don't have a definition of done, or your stories are defining implementation, rather than functionality.
With regard to TFS - TFS doesn't change any of the above, though it does support everything I suggested.
Yes, it's better if you create tasks under PBI even if its only one task, because the PBI was made to monitor product progress, it used story points in estimation (Relative Size), but the task is used to monitor work progress, it used hours in estimation, so every work items have different purpose.
1) The time taken to split the stories out will be reflected in your team's velocity so you shouldn't really have to do anything to plan it in. If you are spending say, half of your sprint in story planning/splitting and getting 5 stories done per iteration, then your plans will reflect that. Through the use of retrospectives you can see that spending less time in story splitting will increase your velocity to say, 8 stories per iteration. Keep an eye out for side effects of spending less time splitting stories though so you can see both sides of the coin.
2) Not knowing the application, I would say that one way of splitting this out would be
Alert User When New USB Device Is Inserted (This would show potentially a default icon)
Alert User When iPhone is attached (This has more specifics around the device, and potentially a different icon/image)
Alert User When Android is attached (Ditto above)
Alert User... (Potentially one for each of the supported devices)
Definitely try to avoid splitting across technical lines such as "Front end" and "Back End". It feels right at first due to our technical nature, but demos don't really have the same impact and your PO and Scrum Master won't really have as good of a measure of progress.
3) Task creation is something that your team needs to figure out. If you're running 2 week iterations and the team is not finding task breakdown useful, then I'd say don't do it. If the team feels as if it helps them break down the work necessary to create the story then, by all means, do it. Task creation for the sake of task creation doesn't make a whole lot of sense IMO.
Hope that helps!
Brandon
I have setup Jira and Greenhopper and set up an initial sprint. I have mostly done scrum during my years via a whiteboard and face-to-face communication. I wonder how I should handle unplanned items using greenhopper? I don't just want to add a New Card and have it screw up the statistics. Would be nice to be able to get a figure of the ammount of unplanned work when the sprint is done. My initial guess was to add a New Card on the Task Board and tag it as an unplanned. But I don't seem to find any unplanned tag for a Card.
I've been using Greenhopper for about 1 1/2 years. It works pretty well and is invaluable to our team but isn't a substitute for post-its on the well for the daily stand-up. Over the 1.5 years, we've ended up collecting a lot of tasks, bugs, and other items in Jira that aren't immediate backlog items. Managing them is the most difficult in Greenhopper. These are the Unscheduled items.
I have these versions set up in Greenhopper:
Unscheduled: this is a holding pen for a few hundred items that we may or may not ever get around to. Some are ideas, some are bugs that we can't fix at the moment.
Unscrubbed bugs: as we find new bugs that aren't related to the current sprint's work, they go in here. Every week or so, we go through them and place them in one of the other versions.
Short Term Roadmap: stuff we'll get to soon but not in this or the next sprint.
Sprint Planning: this is the backlog we work from during planning. It's the higher priority items.
v2.3 - Sprint 2 (or whatever version/sprint we are currently working): This is the sprint backlog.
During the current sprint and before our sprint planning session, I organize the backlog and place the high priority items in Sprint Planning so we will get to them next. After the meeting, we place the items we sign up todo into the v2.3 - Sprint 2 and them manage it on a daily basis.
I think when you say 'unplanned items' you are referring to critical 'hot fix' tasks that need to be done ASAP. In my group we use a split team. We have one team that commits to the sprint. The Core Team. They are the only resource we calculate on to determine the amount of work we can do in a sprint. Another, much smaller team called the Firefighter Team is set aside to work on unplanned, critical items that, for example, might be needed in the next release.
We track these side-by-side. The Core Team is NEVER permitted to work on a hotfix item. However, the Firefighter Team is permitted to lend their skills as 'servants' to the Core Team if they do not have any critical items at the moment. Our split on one project is typically 4Core/2Firefighter. We rotate the Firefighter members each sprint, taking care not to remove someone from the next sprint that is in the middle of a big project spanning multiple sprints. So far so good. The only issue I have right now is tracking what amounts to parallel sprints in a meaningful way. I'll tackle that when it becomes a real issue.
See my feature request to Atlassian and Vote for it.
"As a Product Owner, I want new PBIs quarantined from the Backlog until I rank them"
https://jira.atlassian.com/i#browse/GHS-11139
I have installed TFS 2010 using the Scrum for Team System v3. The work item templates want you to enter a Project Backlog Item that includes story points, then you need to add linked tasks as a child of the PBI. It is at the task level where you can assign team individuals, update estimated hours left, etc.
What is the importance of the Story Points used at the PBI item if individual tasks are using hours?
Has anyone customized this template so that the child work item tasks use story point burn downs instead of hours? Also, I would be nice to have the total number of story points from each individual task roll up into the PBI item as a read only field for total story points.
Thanks for your time.
The company that I work for is also using TFS 2010 with the new Agile Template v5.0. We are going about the process in the following way and having some success. The hardest thing we have done to date is try to wrap everyone's head around the idea that Story Points do not directly equate to any form of hours.
We start the process with a Release Planning meeting, this is done once a week but if you have never done one you probably want to start with one first. We have 3 teams and only the product owners and team leaders are in the meeting, it would just be to large to manage if we were all there. It is at this Release Planning meeting that we, the team leaders only, play planning poker to assign Story Points to User Stories.
Then we have a Sprint Planning Meeting where a team and the Product Owners and Stake Holders will agree to a number of user stories to execute one in a sprint. The Story Points, after a few sprints, give you an idea of how many you can actually don in one sprint. Each User Story is discussed with the product owner and usually the Scrum Master is adding tasks to the User Stories as they hear the team talk them through.
Now the Product Owner and Stakeholders go away. The Team then goes about dividing the work amongst itself and assigning hours (Original Estimate) to each task. After that is done the Team goes to work, usually two weeks but I can see us doing a three week sprint if the sprint just couldn't be nailed down to two weeks.
As we work we adjust the Hours Completed and Hours Remaining with no regard for the original estimate. If we have spent 3 hours so far and after 3 hours we think it is going to take 2 more that is what is on the task, it doesn't matter that the Original Estimate was 4 hours.
Because we have "filled in the boxes" and not adjusted the template all of the reports and the cube just work. We don't need to make any large adjustments to the reports or anything to capture some really nice metrics. If you want a template that is simpler you should take a look at the "Microsoft Visual Studio Scrum 1.0" from the Visual Studio Gallery. It is simpler for sure but offers less reports and less support in the way of integrated Office documents.
Mircosoft Visual Studio Scrum 1.0
We ended up using the TFS Agile template, but just ending up using the "Effort Hours" in the work item tasks and refer to them as story points.