Tag Info

New answers tagged

0

The first question to ask is What does a Story Point mean? If you define a story point as "How much work engineering gets done", then any answer will do. However if you define a story point as "How much value is delivered to the business", then it becomes important to not give credit until a story is 100% completed, accepted and delivered 100%. Modifying ...


0

While searching for the answer I've found this http://blog.eviltester.com/2013/10/android-screen-capture-streaming-and.html and there is the answer: android http://droid-at-screen.ribomation.com/ iOS http://www.airsquirrels.com/reflector/


0

Also user story pointing gives the business a heads up in terms of if anything needs re-negotiating. if you have a month to complete some work you scored as 100 then you might be in trouble. it also gives you chance to break an epic story down into something smaller that still has value and can be completed in a sprint.


0

Ok. i think we've got a solution with the user stories. I can understand how to break them down further now so that they still have value to the business. Part of our problem is tackling too much work at once. This means we have very little velocity for a few sprints and then it jumps massively when everyones work is complete. Our approach is to move ...


9

I think Frank's and Encaita's answers pretty much covers it but there are some additional things to consider: Why use story points The aim of estimating with story points is to give the relative complexity of developing features for your application. A simple way to think about it is take a story you have in the upcoming sprint e.g. a url change. You know ...


3

The fundamental problem here is that it is broken. The PM wants to use planning poker to get an idea of the complexity of each story, with the intention of knowing roughly how many stories can be fitted into a sprint (the team's velocity). As a result, its a "not based on time" that is "based on time". Its no wonder everyone gets confused. There are ways ...


2

After dozens of iterations in my team, we figured out that story points are mostly about medium-term project steering. They allow the product owner to project herself 2 or 3 sprints ahead and essentially make business and scope decisions about a release, based on an average velocity. We've discovered that story points aren't so much useful at a sprint ...


7

Wikipedia explains planning poker quite well. Let me recap some of what's state there with a focus on your case: Why planning poker? First of all, you should all be on board as to why you are doing a planning poker as opposed to a "normal" estimation. The reason is actually quite simple: all of us suck big time when it comes to estimating time for a task. ...


13

Consider the Project Manager's point of view By asking for complexity they want a number that they can compare with your next sprint to find your velocity as a team. They may also be trying to use it to add together your result with other teams to provide an over all estimate on when all the stories will be done. The project manager's is looking for an ...


10

Scrum doesn't know nor care anything about management issues. It's a way to organize your work, and to make problems visible so they can be fixed. Scrum can't fix your problem, but it at least can make it visible. Start doing scrum, making any assumptions you want about resource availability. Plan according to that. Follow the scrum practices. When a ...


7

Your approach of splitting stories into tasks and moving those tasks across the board is very standard fare in Scrum. There should be no need to report on the task-level in TFS, because tasks don't create value to the business. It is the completed stories that create value to the business. If a story isn't fully completed by the end of a sprint, then that ...


0

Lots of good answers here. Hopefully I can add some value with another one... I think one hang up your team might be having is migrating from a non-Agile methodology. That's usually some form waterfall methodology and, in practice, that usually does involve trying to document all technical requirements before a line of code is written. But that doesn't ...


1

TL;DR User stories are for documenting what value should be added to the product, and why. Implementation details (e.g. how the value should be added, tested, measured, or validated) are constrained by the story, but are not contained within them. They are deliberately left as separate artifacts to maintain flexibility and agility within the framework. The ...


1

Make your own decisions The answer to 'So how actually can developers ever develop a story if there are no lower requirements?' is very simple - the detailed requirements that are orthogonal to the needs of the end user (e.g. DB constraints, fields validation, etc) don't actually matter to the user. If the user needs can be met by very different fields ...


1

I think the purpose of this approach is not to constrain user stories, but to prevent bad requirements. In my experience, users are generally incapable of writing requirements. Developers are generally incapable of writing requirements. Heck, let's just admit it straight out: requirements are hard to write! I think it would be valid for a user to write ...


1

I'd say that something like a tree structure works best. You have a few huge 'root' tasks, detailed into smaller but still large tasks, split into small, less-than-a-day, easy-to-track 'leaf' tasks. What you discuss for sprint intake is leaf tasks. But you can always trace them back to a bigger picture, which helps understand which small tasks are more ...


2

Which is Scrum standard/better in terms of your experience? Getting user stories well defined. If necessary, that means getting the product owner in your sprint planning to answer questions. That will lead to two sort of scenarios: You get your questions answered. Sweet, now you can make your small well-defined stories as you normally would. Nobody ...


1

I think if what your Scrum consultants are telling you is that Scrum doesn't require requirements then you have some very poor consultants. They are even wrong to tell you that a user story is not in fact a requirement at all, they just happen to be one kind of requirement. What are the different types of software requirements? Business Requirements ...


1

A User Story is one specific kind of artefact with the goal of describing the interface that the user expects from the system and that is why low-level details simply does not belong there. If you put them there, you are changing the intent of the artefact and it no longer fits the definition of a US. Use other forms of specification to capture lower level ...


6

Smaller tasks are more easily estimated and implemented. Smaller tasks also make it easier to identify when you're "done" with the particular task. The ideal Agile process is highly iterative, so having lots of short but incomplete lists of small tasks makes it easier to iterate through and develop the proof of concept that you're looking for. Likewise, ...


26

This answer will focus on how to work with User Stories and lower level requirements. I won't be discussing the virtues, or lack thereof, of Scrum or Agile. I won't be talking about gurus either. This answer assumes you're on board with Scrum but haven't yet found a way to make it work for you. As others have mentioned, User Stories are meant to cover ...


3

Just don't call this a User Story and everyone will be happy. I think the answer is, you can write this down wherever you want. In general, specific implementations are not included in a user story for a few reasons: You know what the customer wants, but you don't know how it is going to be implemented. The customer is aware there are more specific ...


2

Yup, its BS. And Scrum is not Agile. I hate the rigidity of so-called agile practitioners who tel you that there is one way of doing agile and that you must follow all the rules laid out in the holy scriptures of whichever 'agile' methodology they use. Its all BS. Agile is about being agile. Agile is about getting stuff done with a minimum of overhead. ...


0

We usually do it like this: Product manager adds stories with descriptions to the product backlog. Our scrum master (who is also team lead) reviews those stories and requests additional feedback for stories that are not defined clearly enough. During the planning week, the team breaks down each of the stories to tasks. If bugs are raised, our team lead ...


2

Whereever I have worked in software development, there was always an equivalent of a backlog, always a list of bug reports, and always someone responsible for the priorities (an equivalent of a PO), so your question, though it uses Scrum terms, is IMHO far from beeing restricted to Scrum. A quick google search for "scrum backlog bugs" revealed that some ...


0

Usually it is too time-consuming to estimate hours for items in the backlog. Your team can spend time for hour estimation while this backlog item may never make it to the top. Thus usually only those items that make it into a sprint- are estimated in hours while being split into smaller pieces for sprint tasks.


0

We have a similar setup and Kanban works fine. You can add/remove tasks from boards as needed. It would be difficult to involve external freelancers in Scrum activities, such as sprint planning, daily scrums and review.


1

We allow posting bugs to bottom of product backlog for everyone in the team. The item should correspond to certain rules (e.g. conditions for reproducing, what's the correct behaviour, etc) New features, however, are added to separate list 'Ideas', from which the PO pulls them into Backlog (and obviously turns them into a PBI with more information if needed) ...


13

The usual approach is that anyone can add stories to the backlog. The product owner prioritizes them and the team estimates them. Story quality issues generally get taken care of one way or another in planning meetings or retrospectives. That means the product owner isn't a bottleneck as long as you're satisfied with the priorities he's assigning. ...


5

As pointed out by Bart van Ingen Schenau: The Kanban development method might work well for you. Kanban is a fairly "minimal" method; in particular, it prescribes much less than Scrum. The basic principles are: Visualize the workflow - typically by having (physical or virtual) cards for each task, that move across a board with different phases/steps ...


0

scrum methodology would be one good option for your scenario, with small modifications. When doing the sprint planning, Either exclude n number of persons from sprint and dedicate them for support tasks over the sprint if possible, and in the next sprint rotate the persons who's doing support Or allocate certain amount of effort based on past experience ...



Top 50 recent answers are included