As announced in my last blog post, Satori has been released. It is an initial version and an MVP (minimum viable product). It does fill a need for better time tracking, but there are more enhancements to come. Hopefully a lot more.
Although the initial release is focused on time tracking, there are several areas I wish Azure DevOps were better. Satori is meant to fill in some of these gaps.
The main areas that I wish Azure DevOps was better at are:
- Time Tracking
- Finding Pull Requests
- Update status for Tasks and Pull Requests
- Unified Sprint Boards
- Target Date checks
- Feature/Epic Summaries
- Budgeting
These are listed in the priority it which I'm willing to put some effort towards fixing. And I'm fixing them with Satori.
This blog post gives a high-level vision for where I plan to take Satori in 2025. For more a detailed discussion of the specific issues that will be implemented, see the issue list for the Satori GitHub project: https://github.com/TimothyK/Satori/issues.
Time tracking was the main goal for the initial MVP release of Satori. Most of this is already implemented and covered in my last blog post introducing Satori. Satori doesn't try to reinvent time tracking. The open-source product Kimai already does a great job for that, and Satori integrates with that.
Satori pulls Kimai time entry data to create a Stand-Up report. From Satori you can edit this report. You can add comments, link to Azure DevOps tasks, and all this is saved back into Kimai. From Satori you can also directly create or update Azure DevOps tasks, update their time remaining field and status. The Export button in Satori will update the Completed and Remaining Work fields on Azure DevOps task cards and export to other systems.
That's the current state. In general, you start and stop your time entries in Kimai and use Satori to review that data and add useful comments and links.
Earlier this week Satori was enhanced so that you could stop the time entry Kimai is actively timing from within Satori. Very soon Satori will be enhanced to also allow restart timing a Kimai time entry directly from the Satori Stand-Up page.
I'll also be adding the ability to change the activity, project, or customer assigned to a Kimai time entry from Satori. There are already alerts you accidentally link the wrong Kimai project to an Azure DevOps Task, but soon you'll be able to correct that from Satori.
Splitting a time entry will be added to Satori. Although ideally every time someone walks up to your desk and asks "do you have a minute" you should switch your Kimai timer to that new task, that isn't realistic. It is common to review your last hour of work and split it up so that indicate that you did work on three separate tasks. Kimai has a feature to copy time entries which can be useful for this, but I think I can get it down to fewer button clicks. Much later, it would be nice if Satori could troll other systems (like Azure DevOps, Slack, Teams, or Outlook) to see the exact time you were interrupted and switched tasks.
Azure DevOps does have a very decent view of open pull requests that you are the author of or are involved in the review. It is very difficult to find. It is hidden. You must go to the topmost home page of your organization. This defaults to the "Projects" tab. There is a "My pull requests" tab too. The URL is https://devops/Org/_pulls.
I used Azure DevOps for many years without knowing this page existed. I think it is new. I searched for this. Maybe my google-fu was bad but all I would get were Chrome add-ins to report the PR list, which I did use for years. The very first "hello, world!" versions of Satori (before there was a Stand-Up or Sprint Board pages) was the Pull Request page to show this simple list.
The Azure DevOps "My pull requests" only shows my PRs. It doesn't show or give nice filters for all open PRs in the system. Satori does have this full list of PRs.
It is very limited, however. The Pull Request page was not the primary focus of the Satori initial release. There will be enhancements to this page. It will get filtering so that you can see your pull requests or any other team member.
There are two primary mechanisms in Azure DevOps for tracking work. The first is the Product Backlog Items, Bugs, and Task cards on the Sprint Board. The second is the Pull Requests and its built-in process for approvals.
Our typical workflow for PRs is for the original author of the code change to create the PR (obviously). Then a code reviewer, QA tester, and finally a release manager is added. All three approvals are needed before the code is merged into main. Not all reviewers are reviewing the PR at the same time. The code review goes first, then hands this off to the QA tester, then to the release manager.
Although PRs are great for tracking work, that is not their primary focus. They do not appear on sprint boards. Sprint boards have a totally different mechanism for status tracking. Typically work to be done in a Feature is broken down into code changes that are required in various sub systems, each in their own git repository and requiring their own PR.
On the sprint board are the Product Backlog Items and we create task cards for coding, code review, testing, and release management. These task cards map directly to the people required to author or approve the PR.
Task cards are created ahead of time, in sprint planning, or prior to backlog grooming. They have estimates and "a plan". In the PR approval process, the PR isn't created until the coding is done, and people aren't added as approvers until previous steps are done. There is no planning or estimates related to the PR process, just approval status. Each comment on the PR like a new bug on the board, it would be crazy to log a new Bug for every PR Comment.
There is obviously duplication here between sprint board tasks and pull requests. Backlog, sprint board, and PR lists are different things and do need to be tracked separately. However, they do need to be consolidated a bit more than they currently are.
Unfortunately, there is no view in Azure DevOps where the PR status is shown along side the sprint board or task status. It should be so. This will make it easier for the assignee of those tasks/PRs to make sure the two tracking methods are kept consistent.
This view will be added to Sprint Boards and Epic Views (see below). But initially I'll be adding this to the Stand-Up page, which is the most actively developed page in the system right now.
The Sprint Boards in Azure DevOps are quite good. It is nice how you can drag and drop task cards to change their status. But of course, there are some improvements I'd like.
I am assigned to multiple teams. This means I must visit multiple Sprint Boards to see the tasks that are assigned to me. The worst part of this is that the absolute priority of my tasks is unknown. Each board has a task that is my #1 priority, but which of those two is my real #1 priority?
There is also a lot of scrolling on the Azure DevOps Sprint Boards. It isn't just that there is more white space in the view than I'd like. I find I'm constantly scrolling over tasks that I'm not able to work on. There is a filter to show only my tasks, but many of those tasks I'm assigned as the code reviewer, tester, or other downstream job. Azure DevOps does have Predecessor and Successor links between work items, but they have zero effect on the sprint board (or anywhere in the system as far as I can tell).
I should be able to easily set that my Code Review task is a successor to another person's Coding task card. Then that Code Review task shouldn't appear on my board until that Coding task is done.
Azure DevOps does have a Capacity for team members assigned to sprint teams. The tasks on those sprints have a Work Remaining field and a priority to indicate the order that the work should be done. In theory, the date a task or any parent work time should be done can be estimated. Azure DevOps does not seem to calculate or display the date a work item is expected to be done. There are summaries for all the work in a sprint (the burndown chart), but no date for a specific work item.
I'm not too surprised that this is missing from Azure DevOps. Estimates can be dangerous. Estimates can easily be misinterpreted as promises or commitments. It could be very danger to trust or rely on these calculated numbers. Not only that, but these calculations are not easy (see below). However, I'd still be interested to see what these calculated values would be.
There is a lot of risk that goes into a feature like this. It depends on a lot of things.
First of which is that all tasks must be estimated, and their remaining time updated frequently. Hopefully the features on the Satori Stand-Up page encourage this information to be updated reliably.
Secondly, a unified view of all work needs to be available. Other team tasks may interfere. When a person is assigned to multiple teams, this should be managed by dividing their total capacity across the teams they are assigned to. Every day the expectation is they should spend 2 hours on team A and 4 hours on team B. But it doesn't work like that. Sometimes team A may have higher priority items than team B. Forcing people to multitask hurts productivity. The unified board feature should help in improving the estimated target date calculation.
The sprint boards do not display bottlenecks created by predecessor dependencies. This will be another factor in the estimated target day calculation.
This feature depends on a lot of other features being done. So, this feature starts becoming a stretch goal for 2025. I'll just quickly list off the rest of the stretch goals.
Like showing the PR status next to the Product Backlog Item and Bug work items, there isn't a good view to summarizing all the work items under a Feature or Epic. This view would especially be beneficial to project managers. They'll like also what to see estimated target dates on each issue.
Satori, by design, makes it easy to update the Remain Work field. Also, by design, it does not show the Original Estimate and Completed Work to bias what someone's opinion of what the Remaining Work should be. It thwarts the estimation process to for a manager (or management system like Satori or Azure DevOps) to say, "Your estimate should be 8 hours; what is your estimate?" Chances are the response will be "8 hours". Within reason, it is best to give people the time they need to do a job right.
However, people should be accountable to their original estimates too. It should be part of the Scrum process that before the development team get approval from the product owner to work on an item that there is some understanding of the cost or budget for that work item. There is always unexpected work that comes up, but estimates are usually padded to account for this. There is an Effort field on the Product Backlog Item or Bug that can be used to capture this budgeted amount.
If the estimates on the task cards come close to or exceed the parent work item's budget, there should be some sort of alert. I'd like to avoid showing this to the task assignees immediately for fear of biasing their estimates. But it should be shown to them at some point. Budgets may need to be renegotiated with the product owner.
Well, that ought to keep me busy.