We have a shared work item where two teams work together.
is it possible to create a common PBI which can be visible on both the boards ?
This work item type is dependency.
Google
and
self-exploration.
To work with PBIs, a team should be an owner of these PBIs. In your case, you may just copy the current PBI and add a team-specific description. Then each team adds its own estimate and child tasks.
If you what to use one shared PBIs, that may be not so a manageable structure... Let's say the first team will be an owner and adds tasks for the second team. In this case, the first team sees the full structure in the backlog:
and only its tasks in the sprint:
The second team can find only its task in the sprint as unparented:
It depends on how the sprint/area path configuration of the teams is defined. If both team share their area path, then the PBI will show up on both boards.
Related
How can I add the same work item to two different sprints/sprint boards?
My scenario is given below.
I have a big team that is following a longer sprint length (1-month sprint cadence for example)) and a sub-team that is trying 1-week sprints. I have done the project and team configuration (using area paths and iterations pats etc.) such that the sub-team sees only their backlog view and the big team sees the whole backlog. I can drag the work items from either one of the backlog for either one of the teams to corresponding 1-month sprint board (for the big team) or 1-week sprint board (for the sub-team).
My question is as follows:
The bigger team wants to see all the stories as part of the month-long sprint. In other words when they have standups they want to see the sub-team's 1-week sprint stories also in their sprint board for the month-long sprint. I tried to add the same story into both month-long sprint for the big team and 1-week sprint for the sub-team. But Azure DevOps cannot keep the work item in both the sprints at the same time. It you add it to month-long sprint board, it is removed from the 1-week sprint board.
How I can have the work item be added to both the sprints? Any help is appreciated
You can set up sub-teams and sub-sprints using Azure DevOps logic, then the work items will be automatically synchronized on the backlogs of both teams.
As shown below:
"Team 2" is a sub-team of "Case0103 Team". And "Week 1" sprint is a sub-sprint of "Iteration 1".
Then in Sprints, "Case0103 Team" can view work items of "Iteration 1".
"Team 2" can only view work items of "Week 1".
Here are the detailed steps:
Create a sub-team. You can click Configure a hierarchy of teams for detailed steps.
Create sub sprints. You need to go to Project Settings -> Boards/Project configuration, then choose your sprint and click "New child".
Set iteration paths. Go to Project Settings -> Boards/Team configuration -> Iterations. Select different teams by navigation bar at the top and select or remove sprints. Team members can only see sprints shown here.
I am an automated-test engineer and call it occupational hazard, I keep thinking towards making automated testing efficient and easy.
Couple of weeks back, I was thinking, in fact just wondering, if we could introduce a new process where I force designers/developers to provide me a wireframe for every single or unique screen in the web application.
Example: In a hypothetical web application, if home page displays differently for different profiles like associates, approvers, auditors and managers, I want a wireframe for each of those profiles. But if there are 2 managers (data combinations) in the organisation, I don't expect wireframe for these 2 managers as just data is changing and structure would remain same from automated-testing perspective.
This helps in automation in the following manner:
Say a sprint starts and it's decided that 2 new features shall be developed in this sprint.
Wireframes for these 2 new features shall be provided to the whole team at the begining of the sprint say in sprint-planning meeting.
Using these wireframes I would automate my testcases and when the actual screens are deployed, I would just run my automated-testcases. Of course they will fail due to some minor issues but they will be easy fixes. This is way better than not starting automation until the actual screen are deployed.
If this approach is possible, I will later demand for id and name properties of user controls (like links, buttons, edit boxs, check boxes, radio buttons etc) along with wireframes. I am aware that some teams are already sharing id and names properties of user controls with their automated-testing team upfront so that they can automate the testcases even before actual screens are deployed. You could say my idea is little enhanced version of that.
It sounded impractical so I stopped thinking towards it but later felt like I should ask the community if it's possible? if yes, what's the overhead on the overall design/development team.
Some developers reading this might think that pffhhh... we are packed with stuffs already and this would be an overhead. But trust me. Early collaboration with testers and automate-testers would really help the quality of the application. So if the overhead is well within the limit, we could think towards introducing this process.
Please let me know your views.
I am developing Leave Management System in SharePoint 2013. Employees can apply for leaves and Manager can either approve or reject it.
I have accomplished this by creating a new list - "Leaves" and starting a workflow when a new item gets added. Workflow sends an email to Manager and creates a task item for him to be able to approve or reject it.
However, I would like to know if this approach is preferable in real time scenario. Suppose for organization of 500 employees, can a single list hold so many records for all employees. What are possible ways here to utilize the features in SharePoint and also create a scalable application.
Also, I am also planning to develop a new Add-in in SharePoint 2013 since for applying new leave, we need to display additional information such as available leaves and do some custom validations which are not provided by default SharePoint list. I will be adding the new item to the SharePoint list from the custom developed page so that the workflow still is intact and I am still utilizing out-of-box SharePoint features. Is this the way to go for enterprise level application or there are any other alternatives. Please suggest.
SharePoint Lists are capable of holding that much data. I don't see a problem if you use a single list to hold leave request of 500 employees.
Assume a worst case scenario that all of the 500 employee apply 25 leaves individually in a year, then the item count would be (500*25= 12500) which is not bad.
You will need to take care of the List Threshold error, because data is greater than 5000. For this you can create views which always bring out results less than 5000.
Now lets say you have plan for 5 years, so each year you will add 12500 items which at the end of 5 years will be 12500*5 = 62500 items
Here you can think of 2 options
You can create a list for each year, i.e. Leaves2016, Leaves2017 etc.
In a single list create folders of year, and inside them add all leave datas.
Note: The only major thing you need to take care of List view threshold problem. Which can be tackled with intelligently designing
views
For your second question.
I agree that the OOB SharePoint List form will not cater your requirements. So creating a custom page an add in or something else is a way to go. As far as your data is getting inserted into a list and eventually activating a workflow there is no harm in it.
I've been a JIRA and Bugzilla admin in past jobs, and have quite often had users ask for the ability to have more than one assignee per issue.
I know this is possible in JIRA, but to my mind it never makes sense; an issue should represent a piece of work, and only one person can do a piece of work (at least in software, I've never used an issue tracker for a 2-man bobsled team ;-)) A large piece of work will obviously involve more than one person, but I think in that case it should be split into subtasks to allow for accurate status reporting.
Does anyone have any use cases where it's valid to have multiple assignees ?
The Assignee field means many things to many people. A better name might be "Responsible User". There are three cases I discuss with my clients:
A. number of assignees = 0
JIRA has an Allow Unassigned issues option but I discourage use of that because if a work item isn't owned by anyone it tends to be ignored by everyone.
B. number of assignees = 1
The default case
C. number of assignees > 1
Who is responsible for the work item represented by the issue? The best case I've seen for this is that when an issue can be handled by any one person in a team, so before triage the issue is assigned to everyone in that team. I think a better approach is to create a JIRA user with an email address that sends to the whole team, and assign it to that user. Then a member of the team can have the issue assigned to them in particular.
Changing the one assignee case has the history recorded in the History tab. Nothing is lost in that case.
I'll often have a story / feature that can be split across multiple developers. They will have individually assigned subtasks but it would make sense to assign the parent to all involved, unless there's a lead developer. I wasn't actually aware that I could do multiple assignments, so thanks for the tip!
The other case I can think of is pair programming.
I hit upon this question while looking for solutions to doing this. Since I want to do this, I'm guessing my use case counts as an answer to your question: I only really want one assignee in the sense of someone currently working on a problem, but I want to track the whole lifecycle of an issue. For us, that can mean:
A support person receives a report from a customer, creates an issue
An issue-wrangler reviews the issue to make sure it's valid, not duplicated, has all appropriate details, etc.
A developer implements/fixes the issue
A tester performs whatever tests are appropriate (in our case, mostly extending our automated testsuite to additionally test the feature/fix)
An operations person rolls out the new version to a test environment
A support person informs the customer, who does his own tests with the new version in the test environment
An operations person rolls out the new version to production
Not all issues necessarily go through all steps. Some issues have more steps (e.g. a code review between step 3 and 4). Many issues will also move backwards among the steps (developer needs more information, we go from step 3 to 1 or 2; tester spots a problem, we go from 4 to 3).
At each stage, only one person is actually responsible for whatever's got to be done. Nevertheless, there are a whole bunch of people who are associated with the issue. Tracking systems we've used are happy to offer easy changes to previous owners of the issue (shown as a list), but I'd ideally like to go a step further, with the owner automatically reverting to the correct prior owner depending on the issue's status. At step 6, the original support person from step 1 should ideally contact the customer. At step 7, the ops person from step 5 would ideally be the assignee.
In other words, while I don't want multiple assignees for a given step, I do want there to be a "support assignee", a "developer assignee", a "testing assignee", etc.
We can do this with subtasks and we can do it by manually selecting previous owners when changing statuses, but neither is ideal and I think the situation above is one where multiple assignees would make sense.
In my company, we have a similar workflow to Nikhil. We work in a scrum model, with developers, testers and a technical writer on each team.
The workflow of a development task is
Development -> Developer review -> QA testing -> PO Acceptance -> Done
The workflow of a QA task is
QA writes test case / automated test -> QA review -> Done
We had a tool which JIRA replaced that allowed us to assign multiple people to a task, which we found very useful for our workflow. On a QA task, I could easily see if the other tester on my team had already done work and I needed to do the next step.
Without this, I am finding it difficult to quickly identify tasks written by the other tester on my scrum team which are ready for me to review (versus the ones I wrote which they need to review).
So many people have asked for the ability to have multiple assignees since at least 2007. They have varying, valid use cases. I was disappointed that the JIRA development team unilaterally said they won't implement this and would ask them to reconsider.
https://jira.atlassian.com/browse/JRA-12841
While pair-group working (pair programming etc..) it would be nice to assign both persons to the issue.
Tasks move through different steps through development (example: Development, review, testing). Different persons can be responsible for each step. Even though the task may be in review or testing, the reviewer will have stuff fore the developer to fix. Having different roles to assign to would help organizing the work.
In our team we usually develop 1 or 2 persons together.
Then the code is reviewed by around 2-5 persons in individually or in pairs
Then it is tested by 1-2 persons initially, finally tested by the whole team.
Currently our system allows us to assign a single person at a given time. That limits our ability to follow who is working on what without looking through the log for the issue. The benifits of beeing able to assign multiple persons would be good for us.
What happens if John is assigned a task and cannot finish it, and it is moved to Jane's list because John was a slacker?
Are you OK with losing history of who it was originally assigned to, and the hours that were spent / billed on it?
In an e-Learning scenario, it makes sense to have an issue assigned to multiple users.
Here is what I want to do:
I have a storyboard which I want to assign to 3 people at the same time - the animators, the recording artists and the graphic designers. Once these people finish their tasks, they will pass it on to a common reviewer, who will review and close the issue.
Graphically it would look something like this:
Storyboard
/ | \
graphics animator recording
\ | /
reviewer
|
done
The three job roles depend only on one storyboard. The compilation of the three have to go to a reviewer. I'm racking my brains to get this working on redmine. Haven't found a solution yet.
Got this answer from an Atlassian partner https://www.isostech.com/solutions/
and then later from Atlassian
Objective:
Want to set who does the works for each step on an issue
Summary:
Use a plugin to copy values from custom fields into the assignee field whenever the issue transitions to a new step.
How:
1. Install the Suite Utilities plug-in:
This plug-in adds a bunch of new functionalities to workflows.
You will use the plug-in to copy the value of a custom field to the assignee:
Create a custom field as single user picker for each role i.e., dev, tester, reviewer to be assigned at different steps in the issue
Add these fields to the issue type's screen
Modify the post-function on the workflow transition between each step
Add a "Copy Value From Other Field" post function and set it to copy the value from the appropriate user custom field into the assignee field.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Is Agile/Scrum the answer? How does Scrum handle this?
One Product Owner, One PRoduct Backlog vs Multiple Product Owners and Product Backlogs?
How is it working for you? Please share your success failure stories?
I am trying to put a process together to manage multiple queues of work ranging from
Infrastructure projects, simple feature enhancements and then big projects with a
small development team of 6-7 developers.
One missing bit is whether this is technically one product (like one codebase, even if large) or not.
If those are completely separate products then using Scrum I'd go in very short sprints (1-2 wks) and sequence development work. So two weeks project A, then project B, then C, then again A - maybe for two sprints, then C etc. In such a situation a single backlog makes no sense, separate backlogs should be kept for A, B and C. I know at least one team that works like this.
Whether you need more POs is rather a function of knowledge about products. Maybe you need someone for each project, maybe you have someone who knows well enough A, B and C to be the PO.
If different products then when you try to do it by taking different stories from different backlogs every sprint what you will end up with is split team. Naturally people will specialize in given project, also it will be very hard to have a good definition of done (are we done if we can ship new increments for A and B but not C this sprint?). If you can't sequence projects with short sprints, then I would look towards Kanban for trying to put some organization into this.
If this is one product/one codebase - then things are much easier. Even if the team will have to touch different areas of the codebase because of different projects they will be still working on the same products so all mechanics of Scrum will apply nicely. One backlog, one PO.
One downside of this to be noted is that people on the team will context-switch and there is a penalty from doing this no matter what process you use. Whatever process you pick should try to minimize this as long as possible (as long as business will be able to hold). Nice thing about Scrum is that it has this built in agreement with the PO that context switches can occur only at sprints border - in other words team will get 1-2 wks to concentrate before having to switch to another project.
Also, don't forget about all technical practices of agile. Unit tests. Automatic builds & tests. Code reviews. Clever use of repos. High standards re. quality. All those are a must in such a challenging environment.
I guess you can do two things:
Do one release of one project, when done, do the next
Split up your development team
Or a combination of both :)
Agile/Scrum are nice buzzwords, but don't seem very related to your question.
Since they apply to the scope of a project, not to a bunch of projects.
I have experience with the second option, up to a level where there are more projects then developers, which isn't what you want. But with decent code review sessions it does seem to work.
A little more detail might help.
Is it one big production team, that is sharing lots of projects between them? Is it a small team (5 ish) with lots of projects?
Why do you have lots of projects? Are they working on different time frames, with some being the 'real work' and others being the 'if your not busy do this as a background task'.
I suppose the key here might be the project to developer ratio.
We have a single department of about 15, which runs 3-4 projects at any one time. People generally belong to a project at any one time, but can move between them as projects go through different phases, and as different skills are needed. Test in particular seem to switch projects a lot.
As for a strict process...make the process fit your needs. If we have a better idea of your needs we might be able to make better suggestions.
One critical piece is that the multiple product owners need to be aware of each other and be able to work together outside of the scope of the development. If they're segregated out into their own fiefdoms and each one trying to be louder than the others to get the attention "their product" deserves, then you're going to have problems.
By the time any development work is put before the team, these things should already be straightened out. The developers shouldn't care (or, in some cases, even bother to know) what tasks are for what owners or what projects, etc. They can care and know these things, sure, but it shouldn't be critical.
The product owners and various other high-level roles need to start each sprint with a plan of which stories should be done during that sprint. It doesn't matter how many stories from any given project are included, sorting that out is a scheduling concern for those stakeholders. Working with the architect or senior developer or such, they should simply decide what stories get implemented in the current/next sprint.
(On a side note, I have an Area 51 proposal for just this sort of thing: http://area51.stackexchange.com/proposals/9543/development-methodologies)
IMHO, Scrum is more effective when you have at least 3 to 4 iterations of two weeks with a team of 4 to 6 developers. So for projects of +- 400 man/day
I think it's a bad idea to do multiple projects at a time.
Please also check this previously answered question:
How does Scrum work when you have multiple projects?
It's seems you mix product and project concepts.
I suggest to manage one product development with one team and one product backlog. Don't create separate projects for feature requests of one project. Instead have one team working on different requests from different customers by prioritizing the user stories.
Though, if those are completely separate products you develop, try to split up the team so each teams can concentrate on one product at a time.