Feature List last updated June 2021
Quickly access and manage multiple projects from within the same instnace all related to the logged user account. Based on the user access you may also create new projects.
We only show essential data on this screen, click on any of the loaded projects to proceed further into the project details page.
Designed as a planding page for each project, it brings a summary of all team members, essential vitals for the project itself such as the total count of work items created under the project, the ammount of compleated work items, the ammount of active work items and lastly for the unit testing team the ammount of work items ready for testing.
The screen also includes the project name, the option to quickly manage members and a summary that gives brief update for anyone that is new to the project. Generally an area where you'd describe the main purpose of the project/product so that new members can get up to speed quickly.'
A user specific dashboard that allows each user to customize the look and feel of his project details. Each user can set the following widgets in any position of the screen or use one of our pre built enviroments that already have defined management, development and testing dashboards optimized with what our team uses to develop the solution.
- Work Items Board (using a query)
- Burndown Chart
- Calendar Heatmap
- Team members
Managing Work Items
What is an work item?
Work items are the essential building block in the agile workspace, they come in 7 different types, each having unuque properties and place to go on the planning page.
Epic - This is the essential starting point in any product/project, they represent the end product that you're laying out. Lets say that you have you are planning to build a SAAS solution which will consist of 3 parts, the platform, the webpage and an app that goes with the platform. So in that sense you will start with 3 epics Webpage, Platform and App. There is nothing wrong with keeping everything under a single epic, but its just nice to keep everything organized
Feature - are uniquely related to epics, not nessecerely, but with the intend to be related and specific to an epic. Lets take for example the webpage, in order to create it we will need to define a set of features that will be required in order to get it in production. These can be the following, UI Design, UI Implementation, System Design, Payment Gateway, Authenication/Authorization Page, SEO or any other integration that you might want to add its up to you.
User Stories - here is where we actually start to break down complicated problems into small easy to acomplish goals that will transfer into sprints later on, so lets take the UI Integration feature for example. Assuming that we already have the design we can have the following User Stories. Landing Page, Contact Page and About Us.
Task/Issue/Bug/Test - all of the mentioned items belong under the same level and are used to describe different type of work that needs to be done in order to get the story complete. Lets take the Landing page as an example, in order to complete it we will need at least the following tasks. Implement the UI design (Task), Implement the business logic for authurezation/authenication(Task) and run the following unit test and system tests (Test Case). But lets say the ui doesn't scale nice on mobile and no one cought it while testing, well its easy we just create a bug related to the Landing page story and we are all set for the next sprint to get it patched up.
Work Item System Design
A very important step while planning complicated solution is to have a good design not only on the management side but on the developer side as well, complicated problems might require the team to break down work items into tighly packed and neatly explained diagrams. System design has been a industry standard tool used before agile was a thing and in a sense not that vital for the agile project however extreamly useful when doing long term planning, relational diagrams help visually the whole picture but sometimes we need to drive deep into how a certain component will process the information and for that we need a system design diagram.
We made it so that despite the work item type everyone can go inside our software and start building the system design inside the work item itself as long as his has the write permisions set up the manager with the help of the development team can come up with a detailed diagram that describes the most complicated micro service architecture in details and have it sitting under a single card or split it under multiple cards for future refference making it easy for new members to join the team and explain business logic around the product.
Working with a team even in a structured enviroment such as our software can be hard to keep track of what people did a while ago, this is why we added work item discussions, a single place where people can put messages related for the current work item, for example you might have fixed an issue but its not ready to put on the server. So you can just say to your project manager George, this is ready for testing but i haven't had the time to run i trough, lets leave it for the end of the week i want to focus on more important stuff.
Internal Messaging System
Discussions are a nice addition, but we know how furstrating it can become when you're working with a specific group of people and want to discuss stuff that are only relevant for a specific project. You have optiosn like teams, telegram, skype and many others but all these amazing solutions work really well for communication but don't scale in a bubble.
This is the main reason why we introduce our beta messaging relay built into the software itself, no more issues with accounts apps or passwords for different apps that just run in the background. As long as you are on one of our supported devices (Mac, Linux, Windows, Android) you can access your concoct cloud messanger on the go.
What features does it offer compared to the rest of the commonly used apps?
We have built our interface as generic as possible, each manager can setup voice/chat channels, Internal storage system that allows users to store documents or files related to the current project, setup user access based on tags, managing acounts is easy as creating a tag and giving to any number of users in order to grant them acess to a channel.
Sprints & Boards
Planning boards gives the users a high level overview of everything that has been put into a given project, the screen supports a filter by work item types, generally we use it to get an overview of all sprints and move them across the buckets so that we know that a story has been complete. But it also serves a different purpose, with the planning board you can get a high level overview across all sprints and see which user stories have been sitting in the active state, prioritise them or take measures to break them down into smaller stories so that everything can get moving faster.
Sprint boards is where most people spend their time, different managers handle sprints differently there isn't a perfect formula for a sprint timeframe but usually its not longer then 3 weeks. The idea behind it is to bundle together a coupld of User Stories break them down into tasks/bugs/issues/test then cover every single item till the end of the sprint.
Our sprint board gives the user mostly important the option to quickly visuallize all User Stories in a nicely packed Khanban board broken down into Active work item time remaining, complete and there are 4 default columns that can be also be extended to more columns. The four columns are as follow new, active , ready for testing, resolved. The sprint can be also viewed as a backlog for those that like to work with Grids rather then boards.
At the end of the sprint the manager can click the button close sprint and all items that sit in the new, active, ready for testing will be moved to the next sprint along with the stories themself. In case there are no items outside of the resolved area, the sprint will be closed and all stories will remain the in the closed sprint.
We have built in a changelog generator that generates a list of changes based on the closed work items, the tool has an automated and manual mode that can run independed of eachother.
Automated Changelogs - Set as a system setting the product owner may choose to generate changelogs each time a sprint has been closed, the items in the changelog are redistributed from the closed work item titles generally if you want to use the tool its nice to keep work item titles related and tighly organized. Once a changelog has been generated it passes a review page that the product owner must approve in order for the changelog to be saved. If a changelog has been saved an administrator can always alter the contents of the changelog in case there are naming issues or something doesn't look right.
Changelogs are being served to webpages or other content consumers via the open api module, because of that we decided that it will be nice to be able to create changelogs manually in case you want to include changes that aren't related to the current sprint or the product itself.
Public Projects and Access
Giving users access has never been easier before, with a single click of a button you can add a user that belongs to a different project within your organization or send an invite email to a user that doesn't exist in the organization yet. Each user has a given set of rights withing the system, they must be set before the account is created, to simplify it we have the most commonly used toggled by default.
We have build our software free to use with the intent to empower open source development and cut costs in the devops space along with option to provide ease of access, this is why we created the public signup features, we all know how furstrating it is to keep track of changes on github, that's why we created the public singup that can be enabled for a project.
When a project is open for public signup a link is generated that will be the default gateway for public members, each person that wants to contribute to the project and keep track of changes run builds and possibly help you with the management of a given solution can just create an account for himself and become part of your organization. We understand that most people that do public projects will into the issue where someone will try to delete something and that's why public accounts by default have only read rights and are limited to 4 work items per week unless upgraded by the product owner to a regular users.
Notifications are a very important part in any system, this is why our system supports several types of notifications that all get unified in a single list, notifications are project based, but with a quick setting in the user acount page there is the option for cross project notification bringing everything in a single view.
Notifications provide a quick access to any relevant information that may be associated with the user account, for example a chat message, assigned work item, mention, or even an appointment.
The notification module is build upon SignalR a real time based protocol that uses sockets for communication, all notifications can be pushed to any desktop operating system even if the web app isn't opened. The push notification module supports to following operating systems Linux/Windows/Mac/Android, we also support email notifications and sms notifications that can be configured on a project based level.
Keeping track of changes is important, source controls has become essential for any product development.
Keeping track of versions and changes im important but managing the versions is even more integral to the devops experience, that is why we developed the pull request sub module, which allows uses to open pull requests and manage branches, after a review has been submitted the branch will be put on hold and locked.
When the pull request is signed by more then 1 person it will automatically be pushed into the default branch of choice when setting up the module as active for a project.
Git Devops integrations
Each commit can have certain hooks that run behind it, they differ from the original implementation in git, the hooks in concoct cloud are a set of business rules that may be applied pre, post or when certain conditions are met. Actions may include that a unit tests sequance can be run between the two branches and the result of the branches to prove integrity between the commits, automated build with deployment and much more.
API / Documentation
Built to support multiple of project and designed in mind with collaboration between different softwares the entire cloud is based on open apis that can expose important information regarding a project if enabled.
Each communication happens over TLS or SSL depending on the module that is being exposed, the cloud also provides its own tools for Bug tracking, feedback logging and Open Discussions related to a project.
Documenting certainly is not a thing that comes in mind in any product development, most of the tools come with pretty basic documentation tools and usually relly on third party tools to have the documentation written in and in most cases requires knowledge byound your regular office clerk.
We ran into this problem ourself, that is when we decided to build the documentation module into the software and ease our life, leveraging the power of markdown and WYSWG editors any person can quickly open our documentation module create a category, create a page or sub category and begin writing almost in plain text.
Documentation WYSWG Editor
The WYSWG editor supports, tables, images, headings, lists (ordered and unordered) hyperlinks and other.
The best part the result is entirely partial which means that it can be exposed to a third party website, app or printed in a text based format. The API by default is open and there is a nuget package that allows the user to render the result in static html with custom css so that the page can have the UX look and feel that the consumer reuqires.