Hot answers tagged

18

Actually, your current way of working isn't that far removed from Scrum as you might think. In Scrum, you also get an initial set of requirements, implement those and demonstrate the result, and based on the demonstration, new requirements can be given to you or the stakeholders can decide that the product is good enough that no further development is ...


5

If you think that estimating a story as a 4 rather than a 5 adds value to the planning process, I think you misunderstand the point of the planning process. There is no value in having a highly accurate estimation for some tasks. The goal is to have consistent estimations of all tasks. Also, if you interpreter the points as days, you're doing it wrong. ...


5

You ask for alternatives so I'm going to say eXtreme Programming (XP). Specifically I think that pair programming might help you here. By pairing people with different skills together, it doesn't matter on what skill: making coffee, testing, training etc. you can spread the skills around the team. But to be honest it doesn't sound like SCRUM is that far ...


3

Your situation might be a better match for Kanban, since you can start with you have and iterate from there. This means you wouldn't have a big bang introduction which is disruptive to your current projects - just start by visualizing tasks on a board and adopting some of the practices such as retrospectives and daily meetings. You have to be a bit more ...


3

How to make Scrum work for a team with defined roles? Just do it. According to the scrum guide everyone is a developer but back here on planet earth, different people will bring different things to the table. I nearly got lynched when I suggested that some people are really testers while others write the software. Some things you might want to address: ...


2

As @Martin Maat pointed out, you are allowing change of the scope of the user stories during the sprint, that is not a good practice (it can be from PO as well, does not matter). If this happens often it can be frustrating to the team and makes very difficult to plan releases. Putting this aside, we can generalize the situation as in Scrum tasks can emerge ...


2

When your project goal is to develop a framework to later develop end-user applications, you aren't writing the end-user application. Your users are not the end-users. Your users are future developers, and any user-stories should be written from their perspective. However, the reasons why your users will use your framework is because they are implementing a ...


2

The danger is of course that once the documents are complete you then implement them in a waterfall fashion. I think your approach is probably not a good one. Aglie methodolgies are a response to the problems generated by planning everything in advance and it sounds to me like you are trying to plan everything in advance. Instead of wtiting the document ...


2

Who says that the output of a sprint is only code? One of the deliverables of sprints can be documentation: Once the team gets a business goal, it: Figures out how to do the work Does the work Identifies what's getting in its way Takes responsibility to resolve all the difficulties within its scope Works with other parts of the ...


2

There is no special reason why it's the Fibonacci sequence. Also, in the planning poker cards I am familiar with, there is no 21, it's a 20. So it's not even a Fibonacci sequence at all. The primary point is that you don't have every possible number from 1 to 100 in order to avoid you spend 10 minutes discussing whether or not a story should be estimated as ...


1

The main point of Agile is to iterate instead of doing the big design up front. However, you still have to have the requirements for the minimally viable product which should be documented in some format: specification, user stories, whatever works for your team. It's a lot easier/faster to correct problems in the requirements than to rework\throw out ...



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