Tag Info

New answers tagged

3

In most agile framework implementations, the tasks and stories are meant to be a reminder to have a conversation, not a fully detailed spec. We have had similar problems where new team members who are not familiar with agile or who have missed the planning sessions struggle to work on their own without guidance. The simple solution here is to guide them. ...


0

Write your story. If there is lots of error handling, split it up into 2 stories. After all, the business value of completing the happy path is different than the business value of understanding the reason for an error. Add acceptance criteria that focus on the happy path(s) for each story or the 1 big story. If you have a story for error handling, then ...


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


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


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.


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


-2

I think the solution of this problem is to let team create Issues/bugs within user story, just like tasks. Yodiz (www.yodiz.com) easily resolve this issue by allowing you to create Issues on Sprint board and assign them to a user story. Also same issue can be seen on Yodiz built-in issue tracker so now you can see the same issue at two places on your issue ...


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


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


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


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


0

This is a challenge in--dare I say, weakness of--many of the Agile methodologies. By focusing so strongly and intensely on user stories, user-visible value, and user feedback, they make it hard(er) to focus on "internal" improvements that work down "technical debt" or that prepare the project/codebase for future user-visible and user-appreciable ...


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


0

I think some transparency is needed. Customers are expecting it and it can separate you from a competitor that doesn't take that extra step. For example, you may want your customers to see the status of their request, such as "open" or "closed" in their interface. On the other hand, the admin could have a wider array of statuses that would be invisible to ...



Top 50 recent answers are included