New answers tagged

1

The goal of scrum is to enable the team to be self-directed. There is no universal right way to write stories and tasks. The goal is for the team to work together to accomplish a task. When you write a story and it becomes part of the sprint, your team needs to work together to make that story happen. The first step is a planning session where you break ...


2

Change the hardcoded endpoint so it can be changed. Read the endpoint from a file containing all your settings. Its pretty easy to do, and allows for other settings to be changed according to other parameters. Possibly the easiest thing for you to do is to read the file if it is present, or default to a fixed value if not - this allows you to drop a new ...


0

I gotta admit that I already have one suggestion and I'm posting this question to see if anybody has a better idea. Rewrite the applications so endpoints are not fixed, and the base API URL is defined in a single property with the default value being "http://api.mycompanyname.com" Implement a "dev mode" property in applications. If this property is turned ...


0

The number 1 rule to building your sprint backlog (adding your product backlog items, or PBIs) should be to follow the basic INVEST principle: Independent: The PBI should be self-contained, in a way that there is no inherent dependency on another PBI. Negotiable: PBIs, up until they are part of an iteration, can always be changed and rewritten. Valuable: A ...


0

The primary point of SCRUM (and other iterative or agile approaches) is that it is not known what work and how much of it is required to "finish" the project. At any point during the project new tasks can be added, expanded or removed based on feedback from the customer. This is why SCRUM and other agile methodologies opt into making working software every ...


5

Scrum does not consider things like budgets or deadlines directly. Instead, it seems to provide the program management with the information they need to conscientiously manage budgets and deadlines. Story points are an excellent example. On their own, story points say nothing about how long a task will take. They talk about the complexity of the task. ...


0

Story points are typically a measure of implementation complexity. While there is a correlation between complexity and cost, in most scenarios cost will be affected by a number of other factors. So, story points may give you a rough estimate of your implementation costs, but it will be so rough that you shouldn't really rely on it.


2

Sharing a common core I think it's reasonable to have a common set of core items on your definition of done, but it needs to be flexible. These common items should be clearly obvious and necessary for every team, to the point where there simply is no argument that they should be included. For example, every team should probably have "has unit tests that ...


1

Each Teams have negotiated their own DoD. There are some differences between each DoDs. Consistency has it's place, but until you identify the problems a lack of it causes, it's difficult to come up with a solution. The benefit of Scrum/Agile is to let teams manage themselves. If a team can't come to a consensus on an issue, it's good to have some ...


1

Insisting on imposing a fixed process on teams defeats the idea of working in an agile way. Each team should be free to organise itself in a way that allows it to work best. If that means each team has its own definition of done, then that should be accepted as the best solution. If, over time, the teams talk to each other and settle on a single definition, ...


3

One of the features of kanban, which I believe bleeds over into scrum, is that the process as a whole optimizes for the team, not the individual. In other words, it's no sin if someone on the team is idle for part of the sprint. If the team as a whole chooses X story points, it really doesn't matter (to the stakeholders) whether one person did all the work ...


5

So, how officially are issues of dependencies between stories and inherently serial stories handled by the methodology? As with anything else in Agile: Individuals and interactions over processes and tools If your process isn't serving you, then you mold it into something useful. For this, I would pull in lower priority stories (or some technical debt/...


0

Inconsistency in practice between Scrum teams may actually be a problem, for example if team members move between teams. It would be better to try and go about solving these kinds of inter-team knowledge sharing issues in a more agile manner - perhaps something like running Lean Coffee or Scrum-of-Scrum sessions involving your scrum masters. This would ...


0

I think Kanban would fit better for this situation. Scrum has a few things that do not fit. The timing or scope measurements are not necessary and everoyone developing has the same product vision from the meetings. Accountability and following a short plan with consistency are business objectives. Kanban offers quite a lot of the same advantages as Scrum ...


4

What has happened here is that you've discovered value. The input value was not thought of when the story (and acceptance criteria) was written or when the code was written. If it's not part of the acceptance criteria, you don't really have a basis to reject the story. What we would do on my team is: Create a Bug detailing expected and actual behavior. ...


3

Some observations: ...when I reject his stories I don't know your work culture or process, but to me rejecting a story is a severe step. If I were the dev, I would also generate push back on that as it is a recorded action that reflects badly on me and on the team. He says its unfair since I don't specify the edge cases. It's unfair of him to ...


11

The team needs to work together as opposed to having a "Not my job, not my responsibility" type of attitude/mantra. Acceptance criteria comes in the form of: Business Acceptance Quality Assurance Acceptance Typically the business acceptance is usually answering the question: Does the feature that has been implemented do what I want it to do? The ...


5

Writing software that behaves in a robust manner in the face of incorrect or ambiguous input is an essential part of a software developer's job. If your developers don't see it that way, include additional non-functional requirements in the requirements specification that state this requirement explicitly, and provide your developers with an example of ...


14

I think the answer is you both should be thinking about your own set of edge cases. He as the dev should handle edge cases that are data specific such as does the app crash from any given user input, 5 / 0 certainly falls into this part of the spectrum. The dev should ask about you what you think would be an appropriate error message when the input given as ...


-3

The requirements should be clear and concise. If they are not, then happens exactly what happened to you. It is your fault, and the worst thing you can do when specifying requirements is to assume things. You specific example, about division by zero. If you didn't specify that you want to log the error, then don't complain if the developer prints 100 as ...


3

You're right that Scrum doesn't discuss a lot of details. But that's OK because it's a process framework. For example, Scrum says that the Product Owner is responsible for adding to, removing from, and prioritizing the Product Backlog but doesn't say how the Product Owner does this. That's because everyone who implements Scrum may have a different process. ...


2

Velocity is a historical measure, not a prediction. Your velocity is an average of the past few sprints. If this sprint is your very first sprint then you have no expected velocity. Velocity is a measure of what you have done in the past, not what you plan to do in the future. It appears you've elected to do either 50 or 57 points this sprint. If you are ...


1

You question is very hard to answer. If your stories are all equal in size, all relatively small and can all be implemented and tested independently, than one could assume that your team will be able to continue at its current pace and will possibly finish the remaining 25 point in the remaining days. And if the team is able to finish 50 points this sprint, ...


0

A product development team (that is everyone from product owner, to developers, to testers) can follow the agile process, and get good results given reasonably competent people and realistic expectations. Or they can follow a process that superficially resembles the agile process. That PO probably thinks he will get better results by trying to get lower ...


1

Allowing this behavior is a failure of the Scrum Master. Her job, first and foremost, is to protect the team. The PO, for reasons described above, is being short-sighted. The Scrum Master should step in and, in a positive way, reframe the context of the discussion. Such pressure will, of course, lead to a downward pressure on velocity, something that ...



Top 50 recent answers are included