Tag Info

New answers tagged

3

"[...] reported many critical bugs that needed immediate attention" sounds nasty. If your team can solve 5 bugs per day and dozens of users reported dozens of bugs which all need immediate attention, there is no way you can do what they want. They simply have to wait, and the higher is their leverage to hurry things, the worse it will be, because rushing ...


0

I've always seen the practice that once an issue is assigned, that person takes ownership follows it through to completion (unless there's a reason to pass it off). Assigning every issue to a default person who then routes it to someone else seems like unnecessary handling of each issue. All that interaction will really add up over time.


1

I think how you manage your Jira is really up to you and your team. We use a different issue tracking system to Jira that has the ability to create "virtual accounts". Our last lead developer used to like all issues assigned to him which he would then dish out. When I took over temporarily I created a virtual account called "Up For Grabs" and moved all ...


0

A different team leader began assigning my name to the unassigned issues and changed the setting to the default assignee is myself rather than "unassigned". Does this sound logical? What happens when the task is not in the project backlog - are you removing your name? It isn't the end of the world to put your name there as a default if you remove it ...


1

it is evident that he is upset mainly because I think he considers that developers are “lower” rank than he is I believe this is the main problem. You should have your Scrum Master talk to him about his position. Everyone on the team, including Product Owner, is of same rank and no one has higher authority than anyone else. I believe Agile is primarily ...


-1

All the requirements to make a user story acceptable including errors should be mentioned in "Acceptance Criteria" of the user story. It's responsibility of developer to work with the and discuss all the scenarios pertaining a user story with product owner. Usually by having detailed discussions acceptance criteria of the user story evolves.


0

This is not an Agile problem. Problem is that team does not have enough technical knowledge to complete a user story (agile) or a requirement (traditional). Can Agile help in this situation? No, if the team was not selected carefully and no one in the team has enough technical experience to perform their tasks. Yes, If some of the team members has good ...


1

First let me say that Product owner is the one who decide which story has higher priority, as a developer we give our prospective in release and sprint planning meetings but he/she is still the one who has final say in prioritizing the user stories. The reason is simple, he/she knows the business better. As an agile developer we gotta give our feedback and ...


0

We have been operating on the basis of estimating the story 'cold' during the sprint planning with just some limited discussion. The estimates are really quite inaccurate despite the setting up of teams with a reasonably narrow focus... mainly due to the existence of a lot of undocumented, uncommented legacy code with no real over all idea of what is ...


1

Are the tasks about design expressed as stories and what are your team's definitions of a story is ready a story is done Each story should have his own requirements and conditions of acceptance, but I think it's a good practice to have a set of rules that are applicable to all stories. For instance, a story is ready if (and only if!): the end to end ...


1

In my opinion, there are two different types of planning involved here. Velocity-based planning: Velocity is usually tracked as completed story points in a sprint. You should have a good idea after 11 sprints of your average story point velocity and should be able to forecast how many 'points' your team can accomplish in an upcoming sprint. After doing ...


2

During sprint planning I had to take a wild guess as to how long this undefined user story would take. That's the mistake you did. Nobody can force the team to accept a task in the sprint and it's your job to state that the task can not be estimated and accepted in the sprint unless there is at least wireframe (for example). It seems that your scrum ...


13

how do you handle dependencies in sprint planning? Ideally, non-development dependencies are handled before sprint planning, so that you have a good definition of the backlog item to estimate effort against. But, if that was "just development for you" last sprint, then that was probably going to be just development for you this sprint, so you should ...


6

First off, there is a big difference between dependencies between stories/tasks and uncertainty in the scope/effort of a story/task. Dependencies are handled by giving the dependent task/story a lower priority than the task/story it depends on and possibly an annotation that it can't start before the other task/story is done. Uncertainty should be ...


0

I don't tend to think of tasks as "slices". They are the things you need to do in order to implement a given user story, so are often things like make a schema change, add a new class, add a new method, add a page, style the page etc. You wouldn't typically have one task to implement the whole feature. If you're going to think of them as either vertical or ...


5

Sprints, indeed, depend on the days off. If you have ten day sprints, it's the same as having two week sprints if your team doesn't work on Saturday and Sunday. This also means that you have to be very clear with everyone what does the duration of the sprint mean. If you tell that your sprints are ten days long, some people will understand it as two weeks, ...


1

Short Answer The Dev Team writes the technical things. Scrum helps you a bit but not much with the technical breakdown resp. getting started on a User Story. Scrum is almost What-World-only. The technical breakdown is How-World. The breakdown provided by Scrum is: User Story -> Acceptance Criteria The breakdown people often use on top of this is: ...


0

The short answer is this: the product owner is responsible for creating the stories that the team must deliver. It is the team that decides how to deliver the stories. If part of the delivery involves some technical stories, it is the team that writes those stories. The team then works with the product owner to decide priority. Again, the PO decides what ...


1

Whoever is best qualified on the team needs to break down the requirements from product owners into actionable user stories. In my experience, we've used the following approach: It has always been a developer that writes the stories based on discussions with product owners. These stories are then estimated (based on points or time) by developers The ...


10

In Scrum there is no TL as official role, so let me first answer the question from a Scrum perspective. Everyone in the team can "challenge" a PO in order to get more information, but it is the PO who is responsible for deciding "what" needs to be done. It's important that the team trusts the PO's decisions about "what" needs to be done, and the PO trusts ...


10

Non-agile-hater here. Fleshing out the details of implementation and determining the tasks that need to be done happens during the sprint planning meeting, which will turn the user stories into actual tasks/requirements for the sprint. The failure of many agile processes is that the sprint planning meeting is actually supposed be done largely by the ...


5

If you're talking about a single product/project and a single pool of developers, I would strongly recommend having just one product backlog with all the items you mentioned included in it. Having two backlogs will be an admin nightmare, and I'd imagine that you and the product owner will be fighting for resources to work on your respective backlogs. If ...


0

These issues constitute a "technical backlog" of your project, and what I tend to do is to track them in a manner similar to the main product backlog. In many cases this will mean adding them to your ticketing/bug-tracking system like you would a user story. However, they need to be clearly marked as belonging to the technical backlog rather than the product ...


0

This depends on the nature of your non-user-story-related tasks. Have you considered tracking impediments in your team. In Scrum, an impediment is anything that keeps a team from being productive. The tasks you mentioned could (partially) be considered impediments and you can work on a certain amount of impediments in a sprint. As for who decides what ...



Top 50 recent answers are included