Azure DevOps has three processes out of the box – Agile, Scrum and CMMI. Each of these processes adheres to a particular methodology. Agile being the most universal and widely used. However, the Agile process still brings a set of concepts and behaviors that are not obvious to our new users and therefore some of those users have a hard time understanding Azure Boards.
For example, the 4-level backlog hierarchy or the many state transition rules. These add complexities that new users don’t care about. New users come from tools such as GitHub with very simple work tracking, and they want Azure Boards to be just as easy.
To meet these needs, we have introduced the new “Basic” process.
Keeping it Simple
In order for the “Basic” process to work for new users, we needed to reduce the scope of the process and get down to the basics. To start we reduced the number of work item types down the to three. Epic, Issue, and Task.
By default, users can start right away by adding Issues to their board. You will notice that the board contains 3 columns. To Do, Doing, and Done. This simplified state model is used for all three work item types.
Each of the work item types in Agile, Scrum and CMMI contain many extra fields that are not needed for someone starting out simple. Our research shows that many users get confused by all of the extra fields and their purpose. In the Basic process, we kept only the core fields and removed the rest. Only fields that are required to support other functionality survived. For example, the sprint burn down requires the Task to have the remaining work field. Capacity planning requires the activity field. Here is an example of the Issue work item type. It contains all the core fields plus Effort for forecasting your velocity on the backlog.
Hierarchy is the last area we simplified in the Basic process. Instead of four levels, Basic starts with just two. Users will start with Issues, and those Issues can be broken down into Tasks. For more advanced scenarios, issues may not be enough. Some users may want a way to group their issues into specific deliverables. For these users we are providing the Epic work item type.
See our documentation to learn more about the Basic Process!
Same Great Azure DevOps Functionality
The good news with the Basic process is you still get all the great rich functionality that comes with any process in Azure DevOps. Boards, Queries, Sprints, Dashboards, etc., they are work great with Basic. As noted above, we kept the important fields on the work item types so that nothing has been compromised.
Finally, for those users where Basic is not quite enough and more is needed, you can customize your process as needed. You can add new work item types, fields, rules, etc. Checkout the documentation on customizing an inherited process for more information.
Looking for Feedback
We would love to get some feedback from you about our new Basic Process. We want to know what you like and don’t like. Is it enough? Do you need more? Please email me directly at dahellem@microsoft.com or contact me on Twitter at @danhellem
When this feature come to Azure Devops Sever 2019?
When does this push out?
This feature rolled out to most of the scale units. At this time, it is expected that rollout will by completed by tomorrow (19’th Feb).
We still don’t see it in our AzDevOps env. Either via Create project or Settings -> Boards -> Process
Apologies for the delay Christopher. An unrelated LSI delayed hotfix train carrying this feature. I am hoping that deployment will complete by Monday.
Just wanted to update that our rollout has completed across all rings now and Basic Process is available on all accounts. Please reach out to me at amitgup-at-microsoft-dot-com if you run into any issues while using Basic Process or have feedback on how we can make it better.
Please allow us to switch process rather than start from scratch…
Peter – that’s a fair ask and something that’s in our backlog (though no committed timelines yet). Please do let us know if you find Basic process attractive enough to want to switch your existing projects to it (as you can imagine, switching will involve updating all your work items, states, etc.)…
Is Bug work item type included in the Basic process?
If not, it should be as it a basic concept even in a “Basic process”
I think Bugs are now generalized under the term "Issue", as they are on GitHub. Often, it is not obvious if a problem is actually a bug, or a configuration problem, or maybe just a user error. So it makes sense to start everything as an Issue, and later label it as a bug, after it has been confirmed to be a bug.
I like the simplified approach! Absolutely sufficient for small teams and projects....
Daniel is right on both counts. ‘Bug’ handling starts similar to that in GitHub and allows ‘customization’ of basic process to add more types, fields, states, rules, etc.) ..
And this functionality is not part of Azure DevOps server 2019 RTM, but will likely be included in a future update of Azure DevOps Server.