At the end of the year, it is always nice to look back at how we progressed and evolved within the projects of the last year. This year personally, I learned a lot concerning project and team management, which I’m happy to share with you. In the following article, I will focus on 2 different aspects and how we handled them at my current client:
Within the BI team, we have opted for a SCRUM-based approach. We are not adhering to the strict rules of SCRUM, but have taken the aspect we could implement within our current team and organizational structure. The organizational structure itself is not very agile, so we needed to improvise on certain aspects and compromise also a bit on the strict adherence to the methodology.
At the client, business demands reached our team in a lot of different ways: a quick discussion in the hallway, a mail sent to one of the team members, a formal request from management, … The most challenging issue with these multiple channels, is that you want to avoid not processing the demands or forget to communicate the progress or next steps to your client.
In order to keep track of these requirements, we created a general mailbox for our BI team and put into place a “BI Demands” Trello board where everybody can register demands and provide updates on it. Trello was our choice of ticketing system, as it is very lightweight and easily adapted to our still evolving process.
When a demand is received by any channel, a new ticket is created in Trello in an “Inbox” list to make sure that all demands are registered. At the creation, we add a number of attributes on which we can filter:
So no actual work is performed yet, we only communicate that the demand has been registered and that we will take it up when possible. This acknowledges the business that they have been heard and that we will plan the next steps when the team has time to take it up.
Depending on the impact and the projected work, it is decided which flow should be followed. If it is a small bug to resolve, the bug can be planned directly in the current or next sprint. If it will take up more time, the project passes through a predefined flow. The flow, as defined below, is not yet fully implemented, but this is where I envision we are working towards.
During an initial requirements meeting, we discuss:
After the requirements meeting, an analysis is performed to determine:
After analysis, it is clear whether a project can be taken up and planned or not.
As a BI team, we do not unilaterally decide whether a demand is given priority or not. This decision is taken with all the stakeholders (business, sponsor and team). After the priority meeting, it is clear for the team which projects can be included in the next sprint. This priority meeting is planned once every month, about 3 to 5 days before the start of the next sprint to allow time to properly plan.
The result of this process is that the team can perform the sprint planning without involvement of the business and that the work can be balanced within the team.
Even though it seems a rigid process to follow, it has provided a certain flexibility and peace within our BI team in the last few months.
At the end of the analysis phase, it is clear for the business which project can be taken up and clear for the development team what the next steps are for that project. The business is also made responsible to be clear in the decision which projects receive priority and have the power to influence the decision in a funded and open way.
In the next part, we will talk about how we structured our team and how we planned the tasks within the sprint and did the follow-up. The workflow presented in this first part is not something that was put into place from the start, but it also grew together with the way we handle the sprints, which you will read about in the next article. More to come soon!
In the first part of this article, we briefly touched on the subject of Analysis of the demands which were registered. After the initial requirements meeting, we have a good overview of what is requested by the customer and what is can be included in the development for that project. Now it is up to 1 or more members of the BI team to analyse the work before creating the tickets for the development.
During the analysis phase, we make sure we have the connections we need to the data and analyse the sources which need to be used in the development. This means:
Based on the discussions during the requirements meeting, a number of stories can be created, at the end of which a deliverable is provided to the customer. These stories are then divided into a number of tickets, following a workflow we established during the development of these processes:
All these tickets are created in the “Product Backlog” Trello board and are linked to the correct story and project. Also, all tickets are estimated in number of mandays. This results in a clearly defined workload and structure, which can be planned in the next sprint.
At the customer, sprints were organized on a 2-weekly basis. When starting of the sprint, as a result of the priority meeting, there is a clear view of what projects need to be taken up first and following the analysis phase, the work is clearly defined.
During the sprint planning, the availability of each member is defined for the next 2 weeks. We do not plan all the days of the sprint however. There are 10 workdays in a sprint, but we limit the available time to 9 days, as there needs to be time for sprint planning, sprint review, meetings and administration. Of those 9 days, we only plan about 80% of the time of each developer, as we need a buffer for calamities or other changes in priority.
When planning the work, the tickets are moved from the “Product Backlog” board to the “Sprint backlog” board, this until all the developers are planned for 80% of the 9 days in the next sprint.
In principle, you can only have 1 ticket in “Ongoing” at a time, but a label has been added to indicate if a developer is “Waiting for feedback” or if the ticket is “On Hold”. This allows the developer to not be blocked during the sprint.
There is also the possibility to add tickets directly in the “To Do” or “Ongoing” lists during the sprint, if there is for example a bug discovered which needs immediate response. These tickets are labelled with “Not foreseen in sprint” in order to keep track and analyse the time spent on them during the sprint review.
The sprint planning meeting usually takes up about 1 hour of time, if all tickets in the product backlog have been well defined. As an additional way to communicate the sprint planning to the business and management, we also create a small mind map to show for each team member what the goals are during the next sprint.
When we deliver a story during the sprint, we organize a demo with all parties involved in the development. This is only done when we have the following documentation available on our solution site:
The solution site is a Sharepoint site of the team, where all projects have their proper Document Set. A second requirement is that all the developments must be present in production and the correct authorizations have to be set up before organizing the handoff meeting.
During the handoff meeting of the story, we include:
The goal at the end of this meeting is that all developments for that story are completed and everybody is aligned on the result.
At the end of each sprint, a review meeting is held to analyse how the sprint went in terms of completion of tickets. All tickets which are not yet finished and are in status “Ongoing” are moved back to the “To Do” list, to be picked up in the next sprint. This means also that the estimated mandays on these tickets can be altered to reflect the correct amount of work still needed.
The tickets in the “Done” list are archived, but as Trello keeps track of all these tickets the information is never lost. We can always check back on the feedback and comments in those tickets at a later time.
We also take some time to do a small retrospective in order to analyse what were the pitfalls / issues during the last sprint and how we can improve the process even further. This is usually a very open and casual discussion.
The sprint review and retrospective normally take up no more than 1 hour of time.
Thanks to the work already performed during the analysis phase, it is clear for everybody what needs to be done to deliver a story and how much work can be taken up in the next sprint. Also, because we have estimations of availability and work on the tickets, the planning is fairly straight forward in terms of workload.
We had until now not yet taken up the time to analyse the velocity of the sprints, as the estimations on the tickets were done in mandays. It could however be interesting to add Story Points to the tickets in the backlog, in order to do a retrospective analysis of the velocity during the sprint.
In general, the way we planned the print provided us with a clear definition of what was needed in the next few weeks and the whole team felt comfortable with the amount of work which fell on their shoulders. It even gave us some time to do some non-project related work to further optimize how we handle the overall teamwork and deliverables like the data dictionary, ERD and governance Power BI reports.
We genuinely believe that this methodology gave our team a new motivation and resulted in a major improvement in the quality of developments and deliverables. The work was more structured, even if it was an adaptation of an agile methodology!
Blog By Dries Vlaeminck
Note: this is the second part of my article on sports, data and the link in between. Missed the first part? Read it here.Read more >
I’m curious, I like to write, I like basketball and I’m an IT-consultant specializing in SAP technology. Nothing more is needed for the following piece.
To the article!
Read more >
Many customers have asked for it, and finally, it is available in SAP Analytics Cloud: scheduling stories and dashboards and deliver it to a wide variety of destinations.
The scheduling capabilities are available since release 2020.03 only for SAP Analytics Cloud Tenants based on the AWS data center.
Here we give a brief overview of the SAP Analytics Cloud scheduling features, as was planned in Q1 2020.
In the below-presented SAP roadmap (January 2020), the planned scheduling capabilities and roadmap are highlighted.Read more >