Hot answers tagged

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 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 ...


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 ...


5

The question is general to management roles and speaks about "building people up". Just Googling these 3 words lands countless views and advice — please avoid theoretical and commercial docs, focus on real-world blogs and talks by real people speaking in their own name or their company's (i.e. take advice from those who've already succeeded at what you ...


5

There are three things to consider: Sprint length, Sprint Planning, and Product Ownership. One of the determining factors in Sprint length is the ability to synchronize with the business or stakeholders. You want them to be long enough such that you can get value-added work done, but short enough to be able to incorporate valuable feedback. You also need ...


4

This story is committed for the current sprint. Teams should not commit to completion of Product Backlog Items for a Sprint. The team's Sprint Backlog is a forecast, based on the team's past performance and looking forward for the expected capacity of the team. The idea of commitment only appears in respect to individuals committing to achieving the goals ...


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

The user story is closed when the acceptance criteria is met. So if any team member can check if the story acceptance criteria passed or not, then yes they can close the tickets. If any technical background/setup needed, like creating automated tests, test data..etc. then it's more dependent on the setup or the person who have it on their machine.


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 ...


2

There are a few things to keep in mind when following an agile approach and working with user stories: A user story has to deliver some value, it doesn't have to deliver all the value that is in the final product It may make sense to have intermediary steps that you may not have had if you did not follow the agile approach (because you value responding to ...


2

The short of it, imho: your user stories are too atomic, they're not stories but rather steps it however shows a possible room for improvement in terms of backend design: how "mature" is your API? how modular your backend (microservices vs monolithic, scalability/concurrency, etc) at a fundamental level you're on the right track and if you reverse the flow ...


2

Estimates should be based on effort. Complexity tends to increase the effort needed. Ambiguity serves to widen the cone of uncertainty of an estimate, which correspondingly increases the estimate because when providing a single-value estimate, you generally want to be estimating on the upper side of the cone. But at the end of the day, estimates are ...


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 ...


2

The concept of you impeding a task doesn't make sense, conceptually. An impediment is "a hindrance or obstruction in doing something". I highly doubt that you are obstructing yourself from completing the planned task. However, the bug that you found can be a hindrance or obstruction. I would refer to the existence of the bug as the impediment. If the bug ...


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....


1

In Brief Does it make sense if I impede task 1 under my name? Yes. No. Maybe. It depends. In general, Kanban is about flow. If your unit of work is a task, rather than a user story that represents a vertical slice, then it's certainly possible for a task to be blocked for any number of reasons. However, a task isn't inherently "blocked" simply because ...


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

Adding to the excellent answer from Thomas. A lot of people who are not experienced with software development think that the more features that get implemented in a sprint, the better it is. They do not understand that there are implications for quality and for team workload/morale. Try not to think of the stakeholder as a problem. Instead, work closely ...


1

Yes, you should think about this differently because what you have are claiming to be high-level user stories are tasks. Consider reading the question What is the weighting difference between Epic/Story/Task? to understand better the concepts (which are good enough to be used and followed). In a few words, a task belongs to a user story and, accordingly to ...


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

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

What you need to do is document the facts. Keep a clear record of the forecasts for each sprint and the actual deliveries. Make sure you have dates for each fact. Once you have a few weeks worth of data then you can approach the scrum master and ask them to explain their methods of estimation and suggest ways to improve it. You cannot expect to change ...


1

In this answer I'll start by explain what's the role of acceptance tests (AT) in the context of user stories give an example and finalise by answering your question. To note this answer is adapted from the content provided by the Coursera course "Principles of Agile Software Development", from Instituto Tecnológico de Aeronáutica. Acceptance tests The ...


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

I consider nvoight's answer to be mostly correct, but there are other considerations. In Scrum, the Product Owner is accountable for managing the Product Backlog. In the context of handling requested changes, the Product Owner is the one who needs to remain accountable for ensuring that the request is reviewed, expressed appropriately, and ordered with the ...


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