Agile encourages building software with the end user in mind. It will then help to have a clear and common understanding of this end user within the team. Therefore you can use a so-called persona. Personas represent fictitious people, based on the teams knowledge of the end user. Within this persona you will together write all the details that are of interesting when defining the user stories within your project.
Read More…
Posted in
Agile,
Scrum at July 27th, 2021.
No Comments.
It is up to the Product Owner (PO) to exactly define what he or she expects from a user story within the Definition of Done.
It is up to the team to challenge the PO to have a proper defined user story.
If in the sprint review the PO isn’t satisfied with the end result, saying he or she expected more, the PO is accountable for the result.
On the other hand the team had also to challenge the PO to ask for what he exactly expected from the story.
Both PO and Team are involved, so both are responsible. If the first one doesn’t take the right action, the end destination of the team is very unsure, so changes are big the result doesn’t fit. A PO who has never got time to answer the questions of the team, isn’t a good fit.
If the team fails, they can be blamed asking the wrong or lack asking of questions. Both faults will come at a cost. But be sure you minimize the costs.
Posted in
Agile,
Scrum at February 3rd, 2020.
No Comments.
Code reviews are most of the time introduced within a team to have an additional pair of eyes. Developing is a human practice, hence can lead to mistakes. When you’re developing a piece of code, you can miss things like wrong assumptions regarding your design or code that might cause issues. Things that your peer might address.
If you as a developer put your work to review, it feels like that you have to go to a jury and people will judge your work. Although this could feel like this, it is also an opportunity for you to grow as a developer. Other people might have different insights and give you hints and tips to different solutions. It will also catch up issues and typo’s in upfront before delivering.
What does it take to have a productive and good code review? It first starts with good preparation; knowing what the code does and behave before actually starting to review it. Then we can wrap it up and give the reviewer some suggestions that he can look at, without being aggressive.
Let’s go through these steps and look them into detail with some suggestions how to tackle them.
Read More…
Posted in
Best practices,
Scrum at October 24th, 2019.
No Comments.
One of the tasks when writing software, give an estimation of how much a certain feature is going to take to implement. For the Product Owner or project leader or some other internal customer, it will define which features he or she will get within an amount of time. So it will help the product owner with his or her decision-making, whether the feature must be in the upcoming sprint or not.
We can also determine the velocity with a software estimation, creating a commitment for the team to meet the sprint goals. By knowing how much a task is gonna take to implement, we can put that number of tasks within a sprint which can be handled by the team. Not meeting sprint goals will bring the team into a negative emotional state: “whatever we do, we don’t make it this sprint”. So, people won’t even try their best to meet the sprint goals.
Task estimation seems to be a difficult part of our job as software engineers. Most of the times, it takes more time to deliver features than initially estimated. Why is this and what can we do about it?
Read More…
Posted in
Agile,
Best practices,
Scrum at April 1st, 2017.
No Comments.
Computer systems can become so big, that a huge number of software developers are involved. You might imagine that writing a operating like Linux, Microsoft Windows or Apple’s Mac OS can’t be written by a scrum team which has the size of 6 members. To have an efficient team, you don’t want to have a bigger team. Bigger teams leads to less efficient communication. In organisations which come from the more traditional waterfall method, you see most of the times they have problems obeying this amount of people. You get stand-ups with 15 people or more, which take ages. People can’t keep focused for so long, leading in a ineffective stand-up. It even gets worse when the Scrum Master decides that only one person will represent a story and speak up for three other persons which also help within this user story. In this case, you do the stand-up for the Scrum Master and not for the scrum team (which is all members of the team including the Scrum Master and the product owner).
Read More…
Posted in
Agile,
Scrum at September 14th, 2015.
No Comments.