Search Results

Search found 397 results on 16 pages for 'scrum'.

Page 4/16 | < Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • How to use Scrum and Visual Studio without Team System

    - by Donovan Woodside
    I'm interested in possibly using Scrum with my development team (yes, I know it'll be a little painful to transition over to it). However, we don't have Team System and probably can't currently afford to get it immediately. What are some possible tools for getting a team up and running on Scrum in a .NET/Visual Studio environment without Team System?

    Read the article

  • How have you implemented SCRUM for working alone?

    - by chipk
    I am working alone at the beginning of a sizable open source project and would like to leverage some of the core ideas/methods from Scrum to help manage my time and remain focused on development and deploying early, demonstrable functionality. I would like to hear from others who have used Scrum alone and what you have found particularly useful to these ends. Thanks.

    Read the article

  • Scrum meeting - dealing with the last question

    - by Wizzard
    In the 5/15 minute scrum meeting the 3 questions are asked. For the last question "what impediments are getting in your way" If a dev has problems - the xyz is going to have problems, this is likely going to draw the meeting out past 15 mins and could go into a hour long discussion. Is it the scrum masters job to help this user, is there something to stop this from going on more than 15 mins. Thoughts?

    Read the article

  • When to mark a user story as done in scrum?

    - by Saeed Neamati
    There is a notion in scrum that emphasizes delivery of workable units at the end of each sprint. Each workable unit also maps directly of indirectly to a user story and when in new sprint PO introduces new PBI (new user stories), this means that practically team can't always go back to previous user stories to do the rest of the job, which in turn means that when you implement a user story, you should do it as complete as it's known to the team in that time, and you shouldn't forget anything (something like "I'm sorry, I've forgotten to implement validation for that input control" or "I didn't know that cross-browser check is part of the user story"). At the other hand, test, backward compatibility, acceptance criteria, deployment and more and more concepts come after each user story. So, when can team members know that the user story is done completely, not just for demo, and start a new one?

    Read the article

  • In Scrum, should a team remove points from (defect) stories that don't result in a code change?

    - by CanIgtAW00tW00t
    My work uses a Scrum-like process to manage projects. I say Scrum-like, because we call it Scrum, but our project managers exclude aspects of Scrum that are inconvenient (most notably customer interaction). One of the stories in our current sprint was to correct a defect. After spending almost an entire day working on the issue, I determined the issue was the result of a permissions issue, so I didn't end up modifying any code. Our Scrum master / project manager decided that no code change equals zero points. I know that Scrum points are supposed to measure size / complexity and not time, but our Scrum master invests a lot of time in preparing graphs and statistical information from past sprints (average velocity, average points completed, etc.) I've always been of the opinion that for statistics to be meaningful in any way, the data must be as accurate as possible. All of our data is fuzzy to begin with, because, from time to time, we're encouraged by the Scrum master to "adjust" our size / complexity estimates, both increasing and decreasing them. I'd like to hear some other developers / Scrum team members thoughts on the merits of statistics based on past sprints, and also whether they think it's appropriate to "adjust" size / complexity estimates in the middle of a sprint, or the remove all points from a story all together for situations similar to what I've just described.

    Read the article

  • In Scrum, should you split up the backlog in a functional backlog and a technical backlog or not?

    - by Patrick
    In our Scrum teams we use a backlog, which mostly contains functional topics, but also sometimes contains technical topics. The advantage of having 1 backlog is that it becomes easy to choose the topics for the next sprint, but I have some questions: First, to me it seems more logical to have a separate technical backlog, where developers themselves can add pure technical items, like: we could improve performance in this method, this class lacks some technical documentation, ... By having one backlog, all developers always have to pass via the product owner to have their topics added to the backlog, which seems additional, unnecessary work for the product owner. Second, if you have a product owner that only focuses on the pure-functional items, the pure-technical items (like missing technical documentation, code that erodes and should be refactored, classes that always give problems during debugging because they don't have a stable foundation and should be refactored, ...) always end up at the end of the list because "they don't serve the customer directly". By having a separate technical backlog, and time reserved in every sprint for these pure technical items, we can improve the applications functionally, but also keep them healthy inside. What is the best approach? One backlog or two?

    Read the article

  • Is it appropriate to run a complex enterprise-system configuration and migration project in a similar way to a Scrum development project?

    - by AndyM
    I'm just starting out on the implementation of a large enterprise-wide system, which has complex requirements and many stakeholders. The company has been through high-level evaluation and tender process and determined to purchase a highly configurable "off-the-shelf" product rather than building an entirely bespoke system. The system will replace several existing systems and will require a significant amount of data migration. I'm thinking that the implementation of this system (which is expected to take over 2 years) could be run in a similar way to a Scrum software development project. With the first sprints targeted at building the minimal possible functionality needed (across all functional areas), and then iteratively deepening the level of functionality according the stakeholder feedback. I think this will de-risk the project and help ensure a balance of stakeholder needs within the available time. The user stories are still the same, it's just that to implement them we have work within the constraints of the pre-purchased system. When it comes to 'building stuff', instead of writing custom code the team will be configuring the off-the-shelf package, writing data conversion scripts and the like (and it should be a lot quicker!). Does this sound like a sensible approach? Does the Agile approach makes sense here?

    Read the article

  • Scrum metrics for quality

    - by zachary
    What is the best way to measure QA in scrum? We have members who typically test and they are measured against how many bugs they find. If they don't find any bugs then they are considered to be doing a bad job. However, it is my understanding that the developers and quality people are considered one in the same. I would think that they should be judged against the same metrics... not different metrics then the developers who may also be doing testing work... What is the best way to handle metrics for QA and should QA people have separate metrics from developers in scrum? Any documents or links someone can point me to in regards to this?

    Read the article

  • A key principle of Scrum...

    - by AndyScott
    "A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements." I have been working in a SCRUM environment, with 4-6 week cycles, for about 6 months now and have been very pleased with the impact that it has had on my life (regular work hours, seeing my family, etc).  But was looking up the criteria for a 'Certified Scrum Master' and came across the SCRUM definition on Wikipedia, and started reading the actual definition.  My first thought was "hey, this development methodology actually allows you to deal with what happens in the real world (i.e. customers changing requirements); but is this "selling out" on solid requirements? I understand that this works in the environment that I am currently working in, where there are deep pockets paying the bills, and also making the descisions on what requirements to change / impliment; but is this a recepie for success in smaller or simply more budget concious environments?  Having the ability to be completely flexible when the client wants the product changed.   The more I think about it, the more I feel that SCRUM development may be better suited for an environment where a team is taking over a project from another team (bringing some outside development in-house or something of that ilk), as opposed to ground up development. What do you think?

    Read the article

  • Recommendations for project management software for Scrum

    - by Mendokusai
    We're using Scrum on our current project and we're very happy using our agile board and cards but reporting, burndown charts etc. are somewhat cumbersome to maintain. So, we're looking for good agile software to use instead. I'm keeping requirements deliberately vague but does anyone have any recommendations? The software would need to run on Windows.

    Read the article

  • Which software do you use for SCRUM ?

    - by Rahul Soni
    I checked wikipedia, http://en.wikipedia.org/wiki/Scrum_(development) But I am still looking for some insight from the genius minds using SO. I installed Microsoft Project 2010, and was assuming that it would have some template/plugin that would support SCRUM. Unfortunately, I couldn't find one :-(

    Read the article

  • Testing in Scrum

    - by alex
    In Scrum it's a good idea to test frequently when iteration is finished at customer. But the question is what kind of test should I use when some of the prototype is done with customer? In my knowledge Acceptance test is ok when all the iteration is done - but not some part of it. Examples for the test plan would be helpful

    Read the article

  • Scrum stories and behind the scenes features

    - by James P.
    As I understand things, the Scrum backlog is composed of a series of Stories that represent something for the end user and this is further decomposed into Features. If this is the case, where does all the behind the scenes features go that aren't really linked to a story but are still useful? For example, say I'm making an application that catalogs the contents of a hard drive. A story wouldn't require it but having an md5 hash on each file would be a nice feature.

    Read the article

  • scrum and refactoring

    - by zachary
    If everything in scrum is all about functional things that a user can see is there really any place for refactoring code unrelated to any new functional requirements?

    Read the article

  • Scrum backlog sizing is taking forever

    - by zachary
    I work on a huge project. While we program we end up meeting for endless backlog sizing sessions where all the developers sit down with the team and size user stories. Scrum doubters are saying that this process is taking too long and development time is being wasted. My question is how long should it take to size a user story on average? And does anyone have any tips to make these sizing sessions go quicker?

    Read the article

  • Scrum and requirements

    - by Mel
    You can just have user stories somehow the functionality of the program has to be documented. Do you end up with a specifications document with scrum? If you do do you end up assigning time to do this onto the task?

    Read the article

  • In Scrum, should tasks such as development environment set-up and capability development be managed as subtasks within actual user stories?

    - by Asim Ghaffar
    Sometimes in projects we need to spend time on tasks such as: exploring alternate frameworks and tools learning the framework and tools selected for the project setting up the servers and project infrastructure (version control, build environments, databases, etc) If we are using User Stories, where should all this work go? One option is to make them all part of first user story (e.g. make the homepage for application). Another option is to do a spike for these tasks. A third option is to make task part of an Issue/Impediment (e.g. development environment not selected yet) rather than a user Story.

    Read the article

  • Can the customer be a SCRUM Product Owner in a project?

    - by Morten
    I just had a discussion with a colleague about the Product Owner role: In a project where a customer organization has brought in a sofware developing organization (supplier), can the role of Product Owner be successfully held by the customer organization, or should it always be held by the supplier? I always imagined, that the PO was the supplier organizations guy. The guy that ensured that the customer is happy, and continously fed with new and high-businessvalue functionality, but still an integral part of the developer organization. However, maybe I have viewed the PO role too much like the waterfall project manager. My colleague made me think: If the customer organization is mature and proffessional enough, why not let a person from their camp prioritize the backlog?? That would put the PO role much closer to the business, thus being (in theory) better to assess the business value of backlog items. To me, that is an intriguing thought. But what are the implication of such a setup??? I look forward to your input.

    Read the article

  • How to approach scrum task burn down when tasks have multiple peoples involvement?

    - by AgileMan
    In my company, a single task can never be completed by one individual. There is going to be a separate person to QA and Code Review each task. What this means is that each individual will give their estimates, per task, as to how much time it will take to complete. The problem is, how should I approach burn down? If I aggregate the hours together, assume the following estimate: 10 hrs - Dev time 4 hrs - QA 4 hrs - Code Review. Task Estimate = 18hrs At the end of each day I ask that the task be updated with "how much time is left until it is done". However, each person generally just thinks about their part of it. Should they mark the effort remaining, and then ADD the effort estimates to that? How are you guys doing this? UPDATE To help clarify a few things, at my organization each Task within a story requires 3 people. Someone to develop the task. (do unit tests, ect...) A QA specialist to review task (they primarily do integration and regression tests) A Tech lead to do code review. I don't think there is a wrong way or a right way, but this is our way ... and that won't be changing. We work as a team to complete even the smallest level of a story whenever possible. You cannot actually test if something works until it is dev complete, and you cannot review the quality of the code either ... so the best you can do is split things up into small logical slices so that the bare minimum functionality can be tested and reviewed as early into the process as possible. My question to those that work this way would be how to burn down a "task" when they are setup this way. Unless a Task has it's own sub-tasks (which JIRA doesn't allow) ... I'm not sure the best way to accomplish tracking "what's left" on a daily basis.

    Read the article

  • Discussion: Working TDD in a Scrum context

    - by Anders Juul
    Hi all, When I work TDD I tend to start out with the big picture and create the tests that should succeed in order for the overall assignment to be completed - it then kicks off a number of supporting classes/methods/tests as I 'dig in'. If my assignment has been planned out in detail, I would then open one task, and in order to solve it, open another and then another. Only when the overall tests are succeeding can I close the original task, which means that at any given time, I would have a number of open tasks. I find that this approach conflict somewhat with the scrum approach where, ideally, I should be able to take and close a task within a day's work - and never have more than one task open at a time. I'm looking for input about how you manage this in your project - references to articles are also very welcome, I'm sure this has been debated thoroughly somewhere... The 'answer tick' will be awarded to best comment/reference. Thanks for any input, Anders, Denmark

    Read the article

  • Scrum: What if the Product Owner has tasks?

    - by Lauren J
    I have just started working with a team that has picked up some aspects of Scrum (two week timeboxing) but not others (the team does not currently agree to all estimates or to the number of points in a sprint, but I'll change this soon.) The product owner is also a technical resource (scientist) with some development background. Is it appropriate to have the product owner's tasks (which mostly involve research) mixed in with the team's tasks (some of which are research and some development). I have looked at a lot of resources and not found an answer. Thanks!

    Read the article

  • Scrum burn down charts, can they go negative?

    - by AaronThomson
    I work on a small Agile development team which is part of a large, non-agile thinking corporation. Currently, we practise Scrum and occasionally, we exceed our sprint commitment. My question is, how do you handle burn down charts when you have exceeded your sprint commitment? I can think of two options: Extend the y-axis in the negative direction and keep counting down Add more cards/stories/work and have the burn down value increase by that amount, burning down when that work is finished. The ultimate solution for my team is one which is clear to the business and adds real value for the developers. So far, neither of these solutions has worked out perfectly.

    Read the article

< Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >