Tag Info

Hot answers tagged

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


13

The open/closed principle is a tricky one, and I think it's often misunderstood. In the strict sense, obviously it's impossible to add behaviour to an application without modifying its code, but what we really mean by open/closed is that it should be possible to extend the functionality of a given class without changing that class. Let me try to come up with ...


12

One of the key resources for Extreme Programming is that of Ward's Wiki aka Portland Pattern Repository aka C2.com. This is where a number of people hashed out various methodologies and documented them as they used them. Within this wiki, there is a page: Extreme Programming Code Reviews that has a number of contributors to it, including Ron Jeffries and ...


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


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


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


2

Kanban is an approach that is one that focuses on trying to identify work in progress (and minimize it). Thats the core concept in it. It is based on the just in time workflows of Japanese car companies. Stuff that is stuck somewhere isn't moving as fast as it could through the workflow. Often it is paired with scrum in which case its known as scrumban ...


2

"O/C principle dictates that production code should not be changed if system behavior augmention is required." My understanding of O/C was not that a programmer should not modify a class over time (there's no fundamental risk to tests as we can and should always update our tests alongside any changes to functionality), but that classes shouldn't expose ...


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


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


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

Kanban specificies every user story has to be independent Where did you get this from? Kanban does not require the units of work to be "user stories", and there is nothing in Kanban forbidding you to develop a component first, and then a second component using the first, and so on. And each of this components can still follow a typical Kanban workflow, ...


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

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



Only top voted, non community-wiki answers of a minimum length are eligible