13
The key to team improvement is good retrospectives.
When I started running retrospectives, I found they often just degenerated into whingeing sessions that didn't achieve much, other than giving the team an opportunity to vent our frustrations.
Now I go into the retrospective with a clear goal, stated at the beginning of each one:
We're here to find ...
13
It is worrying that you have no why part to your user stories. This is an important element of the user story format as it allows us to evaluate the stories and to prioritise them. It appears that you are writing technical requirements but partially using the user story format.
I also notice that you focus the stories on the admin, when I suspect the value ...
8
US3 and US4 seem to be the same thing to me. If you need to display the last 5 messages, then that means saving them somewhere, so US3 should somehow deal with that. If US3 does, then US4 is redundant and not needed anymore.
But why do you think you need a database?
As the PO you should not care about and/or decide on technical implementation details on ...
6
There are many things you can do, but the first thing I would start with is a coaching agreement. I've seen very simple and very complex coaching agreements, but all of them hit a few key points:
How will the coach work with those being coached?
What do those being coached want to improve on?
Do we understand and acknowledge that the coach can't improve for ...
6
There are two major impacts of a remote Scrum Master in my experience.
The first is that meetings like the retrospective and sprint planning are a real challenge. The biggest problems are usually with audio quality, particularly if using phone lines or teleconference hardware that mutes the end of the call that isn't talking. If you can get a top quality ...
4
I wonder which of the two perspectives is most useful for the development team that is going to implement my stories?
In all honesty? None. Most useful is the conversation you (as the PO) have with the dev team about the user story, explaining them what needs to be done and what the acceptance criteria is for this particular functionality.
A one sentence ...
4
A key part of the purpose of a user story is to understand the need from the user's perspective. As such, you want to explore their need. This should be their perspective and focus on their need, not the solution. For example, I could write a user story that reads:
As a customer newly registered distributor for ACME Corp, I would like
a confirmation of ...
4
There are two approaches I have seen for this.
1. The development team owns engineering quality
With this approach the non-technical stakeholders (and Product Owner if using Scrum) focus purely on functional requirements. The development team owns the non-functional side of things, will set their own non-functional standards and will add their own work ...
4
It depends on what tools you are using, but I believe that you are on the right track with your thinking about using your ticketing / issue tracking tool and providing appropriate views and filters.
I'm most familiar with Jira, but the way I handle this is that I create a new Jira project for the continuous improvement work, with its own workflows and issue ...
3
There's no right or wrong answer if we just focus on effectiveness, as long as in the end we have the agreed solution built.
The DB isn't even required, one could use the File System writing the users and messages in text files.
The decision is up to the development team to whether or not the DB is developed before, after or during the implementation of ...
3
I'm a little hung-up on how you strictly follow values and principles, but I'll take that to mean that they genuinely believe in them and try in earnest to let them guide their actions.
To your question, I'm afraid there is far more to do still. Think of it like an athlete. When you first start in sports, you have to develop a mindset that training hard ...
2
TL;DR
Refactoring is a natural part of iterative and incremental development methodologies. However, a high ratio of defects in a product indicates one or more fundamental process problems. Such problems represent a cost to the project by consuming budget, schedule, and resources. High defect rates also create a drag on productivity that increases over time....
2
Since you are the product owner, you should think of the product in terms of users. Do users care about the database? No, right? Then you should not either.
Your user stories should be rewritten from user's perspective, not technical team's perspective. See below.
US1: as an admin I want to write a message on a new page dedicated for this matter.
As an ...
2
The requirements tend to define the data structures. If we want to X, we will need to know Y (data). So, you can go ahead and define your stories (from requirements, I hope) and expect the data structures to fall out.
When it comes to implementation, I prefer to work from the inside, out, starting with the data structures (and hardware abstraction). If you ...
2
The real question is, can the team work remotely. Of all the roles, the Scrum Master is not more or less dependent on good communication than the other roles. At least not if they work as a team. Sure, you can lock a developer in a room somewhere and they'll produce code, but that's not what a team is. Teamwork only works with all the people in the same room....
2
Without understanding fully, I don't think we can suggest the best approach. With that in mind, here is my approach based on the information given.
1) Remove the concept of 1 week development, 1 week testing. It should be test as soon as developed, fix bugs as soon as it is tested. This will ensure that your deliveries have as little amount of bugs as ...
1
If you can make this work for your teams then that is fine.
I would caution that a global definition of done has several drawbacks, including:
Getting consensus over several teams is challenging. If not all the teams agree with the final solution then they may ignore it or work around it.
Some aspects of the definition of done may be specific to each team.
...
1
Reinforcing the agile principles is best done by inspecting and adapting.
Once your team understands and applies the agile principles they should look to continually check that changes they make have a positive impact.
This can be done by:
Retrospectives, reviews, health checks, etc.
Metrics (used carefully to avoid gaming)
Surveys
Speaking with customers ...
1
I often found that the opposite is true. "Strictly following" something is IMO against the agile principles. I worked with several teams who were conducting agile rituals every day and talking agile language but who were far away from being agile, especially in terms of "valuing individuals and interactions over processes and tools"
My experience so far was ...
1
Mixing relative and absolute estimation is problematic and difficult. If you were going to use relative estimation (story pointing is one form of relative estimation, while hours is absolute estimation) I would only use that. There will be some things that don't get points (spikes, bugs, etc) but usually this is a small enough percentage of the work in the ...
1
First: It's clear that your testing team is way too small. A ratio of 5:1 is simply going to (1) cause a huge backlog and (2) cause bugs to slip through. Your own project is proof of this.
Even if you could prove that your 5:1 ratio is sufficient you need at least one more tester. A team of 1 tester is not a good idea because you don't have anybody testing ...
1
This can be a real challenge.
Some suggestions that may help:
Have several short demos sandwiched together in the sprint review. Publish an agenda prior to the sprint review which includes times so that stakeholders can attend just for the bits they are interested in.
Consider video taping your demos and splitting them up in to the various features that ...
1
Scrum is based on the principles and foundations of the Agile methodology.
A key principle is the recognition that customers can, and probably will, change their minds (what they want, how they want it, and when they want it). This volatility means that requirements cannot easily be addressed in a traditional predictive or planned manner.
The Product Owner ...
1
There is no standard measure of acceptable quality as each organisation exists in its own domain.
For example, a startup working with a radical new technology may accept a large number of issues as for them speed to market is more important than quality.
A company building medical applications will usually aim for a very high quality standard.
Having said ...
1
RAID logs are not usually maintained when working with Scrum. The reasons for this include:
We release frequently, which often reduces risk
Frequent releases also reduce the need for assumptions
Agile favours individuals and interactions over process and so we prefer to regularly discuss things rather than to rely on documentation
The Scrum retrospective is ...
1
The Scrum Master and the Agile Delivery Manager (ADM) are quite different (According to SAFe) For example:
The Scrum Master has no reporting relationship with the team members, where the ADM is the manager over the team members and is responsible for helping guide team members careers.
The Scrum Master is responsible for establishing Team-level Agile ...
Only top voted, non community-wiki answers of a minimum length are eligible
