Tag Info

New answers tagged

4

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


0

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


6

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


9

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


0

Scrum master is a part of the team and has the right to ask: why did you estimate it that way? Unmotivated, yet proficient teams start to slip over time. Looking for and discussing indicators other than an artificial velocity can help surface this issue. Is their code coverage slipping? Why? Are automated tests failing frequently? Is the build often ...


0

In terms of documentation and handling the change in a strict Scrum framework it should be handled as a new user story and not allowed into the existing iteration but... Let's be practical and not create unnecessary overhead...that's not Agile. If the coding/testing complexity/effort is so minimal that it takes longer to create, prioritize, and manage the ...


0

Assuming you're a product owner or business analyst, don't. Tasks are generally not created by PO's or BAs because they focus on technical details, not requirements. If you're in a dev or QA role think about tasks as tools for the development team to understand the work steps needed to complete the user story. Formal tasking can be a good way of getting ...


0

Depends on the organizational design of the organization and if the product is in a portfolio. Larger, role-oriented organizations are may appoint senior architects to lead these type of activities. Generally an senior architect will facilitate and guide design decisions as they don't just affect a product backlog, they may affect several products in a ...


0

Look for the person on the team that is strongest in these qualities: Knows the general business (not just the customer's business) Has the relationship with the customer Good at logically breaking down customer wants into little business-value oriented stories (Pretty much the Agile BSA mentality) Has process improvement skills Has change management ...


1

While it may be difficult to fully implement Scrum, it can be beneficial to adopt some of the Scrum practices. For example, now matter how you are doing requirements gathering, you can still have frequent releases and demos. You can still benefit from periodic retrospectives. Look at other processes like Lean or Kanban and see if there is anything they have ...


1

As @Contrarian mentioned, the Product Owner needs to understand the requirements and is usually involved in a business perspective with clients or Product Managers who are influencing the overall product releases. Prioritization is a key feature here as well, so this person needs to be granted the power to decide on priority of what to do. In most ...


4

I just read that in XP, tests are written before code. That's not what that's about. Yes, you write tests before the code, but that's a consequence, not the essence. The essence is that failing tests drive the development process, the design and the code. And in order to drive those, they obviously need to exist first. Scrum is a different Agile ...


3

Scrum is a different Agile Methodology but does scrum also involve writing tests before code? Not necessarily. Depending on your locale, writing (unit) tests first is "Test Driven Development" (TDD) or simply "Test First Development". Either way, it is an implementation detail of your development process (how you write the code), not an immutable part ...


6

Generally speaking, the person who knows the most about the application requirements or has the responsibility for interfacing with the client is the one who should be the Product Owner. If the development managers in your organization have the best knowledge of the product's requirements, then they ought to by the Product Owner. Developers need to be able ...


3

You have a very superficial understanding of user stories. That's fine, but you should know. If you really want to understand this topic, then I highly recommend you look at the work of Liz Keogh, Dan North, Chris Matts, and Jeff Patton. Have fun. Don't overthink tracking this stuff in Jira. It's just a fancy to-do list. Here's a story. What's left to do? ...


1

Working in shorter and shorter iterations makes all these handoffs more and more expensive. You can reduce these costs by following a stupid, simple rule: cut batch sizes in half, change how you work to make that comfortable, repeat until happy. Take your 5-story sprint example. If your teams are accustomed to write the code for all 5 stories, then testing ...



Top 50 recent answers are included