LEARNING 1: How to frame backlog items (both product and sprint) in particular user stories
When we started creating our user story for the development of our website, we had problems in actually looking at the process from a user’s perspective. We had a task description given on NeuroK and, of course, we wanted to include all these items. But converting these items such that a potential user would find them interesting was a challenge to us. In particular, framing it in a way a user wants it was tricky. Hence, it took us several iterations to get it working in a way that fits us well. We started framing it as “As a user, we want”. Already in our first meeting, we came to the conclusion that this wouldn’t help us much because the definition of the “user” was difficult to grasp (was it the professors, us, or potential outside people checking the website). Hence, we changed to framing the backlog into what “we” wanted (including professors and ourselves). While establishing the sprint backlog as a separate Trello board (see learning 3) we also realized that phrasing there has to be different than on the product backlog. In the end, this phrasing fits our demands perfectly as it includes the will of the entire team.
LEARNING 2: Understanding what responsibilities come with our roles
A second key learning for us was to understand what our actual roles for the project entail. What does a scrum master really do? What does a product owner do? Despite the classes covering these questions, we were unsure on how to apply this to our group in the actual setting. After immense discussion within our teams and gathering feedback from the professors we realized that the product owner has to make demands to the development team and sometimes also pressure the team to get things done. For our team this came to play especially when we were approaching deadlines. Nevertheless, our development team also learned that pushing back the product owner needs to be done sometimes too to realize a good product launch. For instance, during mid-term exams the development team was asked to finish and implement further content on the website. But with exam pressure on the side, the development team didn’t see itself in the position to provide this in an accurate way. Hence, the entire team arranged on pushing back the content production to the next sprint. The scrum master had to act as a mediator in between the team.
This video helped us immensely in understanding what our roles entailed.
LEARNING 3: Improving visualization with two backlogs
When we first created our backlog, we made use of a single board on Trello, with each card standing for individual elements or requirements. Each of these elements, as we call it, then had a checklist in them where we listed the tasks that were to be done. Now, this seemed like an efficient way to handle our backlog at first, but during our second sprint, we started to realize that it made it harder to collaborate. For instance, if I were to log on to the backlog and I saw that there are currently 3 elements on the “In Progress“ column, I could go on to any one of those elements and start working on the task that was not “ Checked“. This sounds simple enough, but the problem was that we could not see the stage that each of the tasks were in. There was no way for me to know which task had move to In progress or Done. Hence, there was always a risk of two people beginning work on the same task, requiring us to actually constantly inform people about what we were currently working on. Now, when you consider the time that this consumes, especially in a big project with several tasks, this would not be a very agile way to proceed.
Therefore, to improve the visualization of our boards, reduce risk of wasted time and resources, and to improve transparency among the team regarding tasks being worked on by each member, we decided to take our Professor Agustin’s valuable advice and create two separate board on Trello – Product Backlog and Sprint Backlog. As the names suggest, the product backlog contains the elements (requirements) that we need to work on, and the sprint backlog details, in an actionable way, the tasks that we need to work on for each of these elements. Having done this, we noticed that our jobs got a whole lot easier, and prioritizing the element, tasks, and the process of keeping updated on the progress made got easier as well, significantly improving our efficiency as a group. (check out our scrum meeting snapshots to see the boards)
Kommentare