I have got 2 teams one dealing with Bug Fixes the other dealing with small enhancements and have created these 2 teams in VSTS.
I am now trying to plan the work for 2018 so that we have a guide on how much work we can schedule into the releases throughout the year.
I am trying to link the 2 teams and the work into the overall plan so that if (for example) we get more bugs than usual we can demonstrate what that is going to do to the overall plan as this will impact against the ability to deliver small enhancements as bug fixes will take priority.
You can use the Portfolio Management settings of VSTS. This allows you to specify work at a higher level such as epics and features and then distribute the work across multiple teams.
You can then use the Delivery Plans extension to plan work across multiple sprints.
Related
Context
I'm managing an Azure DevOps organization that is intended for an entire global department, where several types of teams work and collaborate together. The entire use case is similar to internal customer support (there are Requesters needing something and Agents doing the work), for which we mostly use Azure Boards (and Repos for Wiki, but we don't use any Azure automation, pipelines and such).
Current structure
4 process templates - I believe I can base all projects on a single
master template, though
2 projects on each template
Idea
Consolidate all the projects into a single project. However, I am somewhat afraid of performance and cannot find good resources confirming (or not) if the platform can take large traffic.
Current traffic
7 projects
10k work items weekly, largest project produces 4k work items weekly
1700 users
~100 teams
Question:
Does anyone have experience with running one large project with such traffic?
The total size of our userbase is not that big - it's 200 so-called agents and probably 1500 requesters. These numbers will grow over time.
One thing that would be impacted for sure is queries, as now we're querying from those 4k items weekly, but in a one master project it would be each query looking initially into 10k weekly items.
One potential mitigation of this is archiving some work items to a separate project every, say, 3-5 months.
Ok, enough data. If anyone can share their five cents, it would be great.
Azure DevOps organization management - one large project?
This is a matter of taste selection.
Accoring to your Current traffic:
10k work items weekly, largest project produces 4k work items weekly
1700 users
~100 teams
Personal experience does not recommend consolidating all the projects into a single project.
Consolidating all the projects into a single project helps us see all workitems on one boards. However, since you have more work items, this reduces the efficiency of query and management.
Azure devops also limits the results of the query：
I am about to start a project for which we will use Azure Boards to track progress of our work items in Kanban-style. Would like to ask a high level question as I am a beginner in Azure boards and have to make a decision on how to set up 11 Kanban boards.
We have decided it makes sense to have 11 boards, one for each category of product in our company. A few pointers:
There will be a single team working through the work items in the eleven boards
There will be moments where the team will be working simultaneously with more than one board
The eleven boards should contain the same team members / columns, as the workflow is exactly the same across those 11 boards
My question: should we create 11 different projects OR 11 teams within a project to get our eleven boards? What kind of rationale would make me want to create different projects as opposed to different teams?
Thank you
When to add another project
In general, we recommend that you use a single project to support your organization or enterprise. A single project minimizes the maintenance of administrative tasks and supports the most optimized / full-flexibility cross-link object experience.
Even if you have many teams working on hundreds of different applications and software projects, you can most easily manage them within a single project. A project serves to isolate data stored within it. You can't easily move data from one project to another. When you move data from one project to another, you typically lose the history associated with that data.
Reasons to add another project:
You may want to add another project in following instances:
To prohibit or manage access to the information contained within a
project to select groups
To support custom work tracking processes for specific business units
within your organization
To support entirely separate business units that have their own
administrative policies and administrators
To support testing customization activities or adding extensions
before rolling out changes to the working project
To support an Open Source Software (OSS) project
If the above conditions are not met, we generally recommend that you create multiple teams in a project. Here is the official document you can refer to.
I think this question belongs here (but it is may get voted down). My company is migrating from GitHub to Phabricator. But, not sure how to implement the "boards" feature. I've never worked on a team that used kanban. We have created 8 different "projects" in Phabricator, but we are too small to have separate teams for each project. There are 4 columns for each board:
backlog
selected
in progress
done
How do people get 1 board for doing planning across projects. The only thing I can think of is to create a "master" project that every task gets added to in addition to it's "real" project. For example, an task might be:
Allow support user to resent password reset email
And it would get tagged with the projects "master" and "support_app".
Is there a better way of doing this?
You can plan an release and add milestones for product level and add multiple projects in it and spread it across team members in multiple projects in further small tasks.
Then you will have an individual task board for each team on team level tasks.
A team member then exist across multiple projects and you can also view , how an person is loaded across multiple projects.
If you want to look at bigger picture then you can see the milestones/release level status.
In our organization we have 6 teams:
3 "project" teams who provide software to the end user
3 "supplier" teams who provide component software to the project teams
I am the leader for one of the supplier teams. I manage code which is standard across the 3 project teams, yet configurable for the 3 project teams. The code is divided into "static" and "config" code. The static code is meant to be the same across the 3 projects; the config code is meant to be different in each project.
I have to orchestrate a rather large team to make my 1 supplier team's deliverables. We are a distributed team, with 6 developers on-site, and 4 different contracting houses providing code which contributes to my "mainline". Each of the 5 sub-teams contributes to a different part of the mainline, but we are allowed to touch each other's code. Total around 35 developers.
What would be the best SCM tool to use, and how would you set it up? Constraints: no budget; unwillingness from management to accept the risk of introducing a new tool. In short, the current in-house team of 6 must continue to use VSS, while I (the build master) might have the ability to buy a tool (1 license only) to help me manage the flux of code to/from the contracting houses.
It looks like Accurev might be a strong contender but I wanted to poll the community. Whatever tool I buy would have to support (somehow) merging code into VSS and being able to provide (nightly?) builds to give to the other teams off-site.
"distributed teams" means DVCS, Mercurial or Git.
Don't even try to manage code/patches with a CVCS (Centralized VCS) amongst distributed contributors, you would only end up re-inventing what a DVCS does naturally anyway.
If you really need to maintain local VSS repos, you can try git-vss in order to facilitate import-export.
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
We are currently utilising an agile environment in work. One of my tasks involve setting up a release timetable. A part of this is providing a time frame of how long a project would take to go from a development environment, to staging and then live.
I have conflicting thoughts regarding whether such a timetable needs to be done.
For a start, we are quickly moving into a Continuous Integration / Constant Delivery environment where an application is tested amongst all environments when a change is made to the code base. Therefore, there is no time frame, but things should be "just" deployable. (Well, we always need a little bit of contingency as the best laid plans can always go awry)
Can anyone steer my in the right direction on what would be the best way to handle such time tables and timeframes if needed in Release Management in an Agile Product Development Environment.
Regards,
Steve
Can anyone steer my in the right direction on what would be the best way to handle such time tables and timeframes if needed in Release Management in an Agile Product Development Environment.
First of all the Scrum Framework guidelines never guides you to not have a Release Plan or Time table ever. What is leading you to have conflicting thoughts? I would like to know the source which is leading you to this conflict.
Best way to create a Release Plan is like this (this may take a week or so depending on the size of your project):
Get the Stakeholders in a room and get a EPIC user story written on the board using their guidance. The EPIC user story should include the end product vision. (ignore if already done)
List out the type of users.(ignore if already done)
Break the Epic user story into smaller and smaller chunks of user stories till they are small enough to be doable in sprints.(ignore if already done)
Ask the Product Owner(s) of the Scrum Team(s) to prioritize the stories in the uncommitted backlog list(s) Also do some form of effort estimation fairly quickly and do not waste a lot of time estimating.
Get the target end date or Go Live date of the project from Stakeholders.
Divide the time frame from now until the end date into Releases. Ask the stakeholders which features need to be delivered by when and include the appropriate user stories in them, and call them Releases. You can also give those Releases themes if needed.
The Release Plan now is conceptualized.
After this draw it on a white board or put it in a visible and transparent location where everyone can see it - add user story cards to the appropriate release.
Now your initial release plan should be ready
Ideas for implementation:
Form a Scrum Team specifically for Operations Activities. They could follow Scrum or Kanban would be better.
As and when Development teams get "shippable products" put in the shelf, the Operations Kanaban Team can do the deployment and release branching etc tasks as per the Release Plan.
So this way the development Teams don't really focus on the Release plan or work, just the Operations Team does that. The Development Team just focussed on the Sprint Work, it would be the Product Owners headache to make sure the right user stories are in the right Release and in the right order. The direction would be given by the Stakeholders.
To be honest you really don't have to do anything yourself, it's all in the stakeholders and POs hand, I don't know where is is the fuss??
I hope you get the picture.
I usually maintain a release plan for the management that is mainly based on a combination of the estimated & prioritized user stories (I group them to match a main new feature of the product) and velocity.
With a well maintained product backlog it's pretty easy to do your release plan. I usually plan three to four releases a year.
What I like with Scrum is that I can potentially release after each iterations.
If you want to master your release management, you will need more information that few answers of practionners. I highly suggest you this book.
If you currently utilising and agile environment you should check Agile estimating and Planning book for some suggestions. This book also contains small chapter about Release planning.
Some release planning should be always done. Release is a target wich usually covers 3-12 months of development = set of iterations. It something which describes target criteria for project to success. It is usually described as combination of expected features and some date. Features in this case are usually not directly user stories but epics or whole themes because you don't know all user stories several months ahead. Personally, I think release is something that says when the project based on vision can be delivered. It takes high level expectations and constraints from the vision and converts them to some estimation. You can also divide project to several releases.
But remember that three forces works in agile as well. There is direct relation among Feature set, Release date and Resources (+ sometimes also mentioned fourth force: Quality). Pushing one of these forces always move others. It is usually modelled as equilateral triangle (or square).
There are different approaches to plan a release. One is mentioned in the book. It is based on user stories estimation, iteration length selection and velocity estimation but I'm little bit sceptic to this approach because you don't have simple user stories for whole release and estimating epics and themes is inaccurate. On the other hand high level feature definition is exactly what you need for three forces. If you don't have enough time you will implement only basic features from all themes. If you have more time you will implement more advanced features. This is task for product owner to correctly set business priority when dividing epics and themes into small user stories.
The most important part in agile is that you will know more quite soon. After each iteration you will have better knowledge of your velocity and you will also reestimate some planned user stories. For this reason I think the real estimate (accurate) and realease date should be planned after few iterations. As I was told on one training effort should not be estimated, effort should be measured. If anybody complains about it show him Waterfall and ask him when will he get relatively accurate estimate? Hint: Hardly before end of analysis wich should be say after 30% of the project.
It is also important what type of projects do you want to implement using agile / scrum and how long will project be. Some projects are strictly budget or date driven others can be more feature driven. This can affect your release planning. For short projects you usually have small user stories and you can provide much more accurate estimate at the beginning.
This is a very loaded question, and depends on your company to be sure. I first have to ask, why are you using 3 environments and continuous integration (your reason matters)? Are you performing automated tests at all? How are your code branches setup? Do you release for some functionality, or just routine maintenance fixes?
Answering these will give you an idea of why you need a release, and how you should go about it.
For example, if you only have a staging environment for the purpose of integration and perform automated tests, then can't having a separate code branch in which continuous integration tests run be sufficient?
If staging is to perform some sort of user acceptance, does your company have a dedicated testing team or are they members of the agile teams?
As you correctly stated, if the code is always integrated and tested, then why would you need a timetable and moving from environment to environment unless you were unsure about the actual "done" condition of the features? By that, I mean that it's not that you're unsure that the feature was coded correctly, but are you worried it will introduce other bugs? Will it integrate well with code already in production? Address the concerns at the root of the problem. Don't just do it because you think you're supposed to have X environments or testing should be in another group. Maybe the solutions to those problems may be to adjust the definition of "done" accordingly.
As you can see there are many, many factors that will make your organization unique. There is no one right way to answer this, just tradeoffs that you are willing to accept.
I find that having multiple environments with teams of people working at the various layers tends to be anti-agile and counterproductive. The best bet is to analyze your concerns, and try to find ways to solve them (such as expanding the definition of "done", or breaking up the various organizations and putting them on the teams, eliminating as many environments as possible and simplifying the process, etc). That may not be possible in your organization, so you may have to live with tradeoffs.