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
here in my company we're using SCRUM with TFS and sprints two weeks long, we have to maintain basically .net applications (web, desktop), android apps, and SAP programs.
So, we can't create a full sprint because there isn't enough work to do, but, at half sprint start to appear more Product Backlogs to take care of and everybody starts to apply pressure so their PBs be finished quickly (Basically emergencies).
We can't wait for the sprint to finish to attend this emergencies so we change priorities on the fly. So basically the sprints mean nothing to our team :/ and all the pretties charts lose meaning.
How we can deal with this, we are not living a project like day by day to have the knowledge of what tasks are going to appear at the next sprint.
Maybe Kanban would be a better approach if you can't commit to a two week timeboxed period but still would like to follow a formal process where "charts" make sense.
http://kanbanblog.com/explained/
You can add as many tasks as needed to capture the work required to complete each item. For example, you have a task in Future Sprint, but you would complete it in Current Sprint, you can move this task to Sprint1:
More information of Sprint Plan, you can check:
https://www.visualstudio.com/en-us/docs/work/scrum/define-sprints
https://www.visualstudio.com/en-us/docs/work/scrum/sprint-planning
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I need to have more control on backlog....
Years ago, we have created a project using a SCRUM Process... Not all developers pay attenction to use correctly TFS... There are many problems I'd like to solve step by step...
First one... I would like to prevent to close a PBI until subtasks opened exist. Can be possible? I have looked for on google... I have looked for settings everywhere on tfs but it seems it is not possible... I remember that on Jira could be possible... is it possible that Microsoft haven't implemented this option?
Do you have any idea to avoid that subtask remain opened when parents are closed?
Thank you
There's no way to do that. The state of work items are totally independent of all other work items, including linked work items.
The best way to manage it at the moment that I've seen is to either:
Handle it via process: Be diligent about reviewing the sprint board and don't close user stories with open tasks
Write a work item query that shows you this information. Something like this will do the trick:
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 have 2 developers that are working on 8 applications. Should I split them in separate projects or keep all in one project? If i should split them, than how can I work with aggregated agile board? Keeping separate agile boards is not very useful because since there will be much more agile boards then developers.
My personal preference is to keep TFS projects for a group of related applications. For example, if you have a website, an app, a webservice, and a scheduled task all working on essentially the same data but for different scenarios, I would group those as a single TFS project.
However, if two applications are fundamentally different they should be segregated from each other. For example, one is a mobile eCommerce application, another is a video game about elephants fighting zombies armed only with a canoe paddle.
That way, the task board makes sense from a logical perspective. With related applications, you'll have stories that cut across all of the projects. You may have a common data layer service, or perhaps they all use a common engine that you want to be able to maintain on the same cadence.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I edit my post to be more specific.
I wish to start using Scrum methodology, And would like to know how the Design and Scrum live together ?
In the "Old" world I would build a complete design for my application, saying exactly where each menu should be, and how many buttons it should contain.
By being so precise, I help my dev team to understand where to build reusable components (Such as a menu UI, that will be inherited by sub menus), and give them a "Big Picture" about the app.
How is this dealt with in Scrum ?
In Scrum we work by sprints, and it seems like a problem for developers to see a "Big Picture" about the app, because there is no "Big Picture", there is only the next sprint.
Thanks a lot,
Michael.
You can always give "the big picture" regardless of which methodology you're using. Very briefly, for scrum/agile, you have to remember the goal is to create a working software at the end of every iteration. So, one of your stories would not be create the upper menu, it'll be create an upper menu that has one specific function. Imagine if the whole project is stopped after any iteration, you should have an usable application out of that, no matter how limited it is.
Development methodologies cannot be effectively described in a 200 word SO post. IF you want to learn about this, read one of the books or take one of the courses.
And, with most development methodologies, either the "high level planning" has already been done by non-developers, or a "plan" has been thrown over the fence for the developers to pretend to follow while they do what they've always done.
And "Agile" is, ultimately, just that -- developers do what they've always done. Only with "Agile" you can admit that, rather than pretending to follow some grand (and fictitious) development schedule.
"Scrum" is just a regular technical/planning meeting between developers on a team, with as much of the busy-work as possible removed. There is no real blueprint or format (though the general rule of keeping it short is good).
There ain't no magic.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have not found much benefit to assigning the top level bug or product backlog item to an individual... since each one has a set of tasks associated with it which are assigned to individuals. Once each task is done I mark the top level item as done.
I'm wondering what the benefit of assigning them to users is?
I can't think of any benefit to the developers having both, however.
Project Server Integration
Some people only sync the PBI/UserStory level to Project Server, so assigning these to people can be valuable to project managers using project.
Owner not Doer
Something else I've seen is people assigning the PBI to the person in charge of keeping it up to date, or just whoever had the original idea. This way people know who to talk to if there's any questions about the PBI.
Personally I leave them unassigned too.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
We're using TFS Work Items to manage our bugs and work items.
Would that be possible to use TFS for agile scrum project management? e.g. defining user stores, drawing burn down chart and cumulative chart, etc?
How?
Thanks
Absolutely yes.
Generate a new Team Project choosing the default process template (MSF for Agile Software Development 5.0) during the Wizard execution.
Now within this new Team Project a great deal of ready-baked reports is available, 'agile' work-item type User Story as well. Out-of-the-box sprint planning is also quite nicely delivered.
With a small time-investment for orientation, customizing & tailoring to your own needs should be possible.
A very comprehensive presentation by A.Bjork was really helpful for me.