Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
This may be a weird question and please bear with me, I am completely new into this.
I have a list of 20 requirements (use cases) which I received from my client. With him, I prioritized this list of requirements (1 highest 3 lowest). I wrote for every requirement a use case scenario (rather than user story). I also have a use case diagram and some technical designs (class diagram, database diagram).
Now, my plan is to separate this list of 20 requirements into 5 sprints. Each sprint lasts one week.
During every meeting with my client, I can show the product with 4 new use cases implemented. If one of them isn't finished, I move it to the next sprint and my client can request a change during this meeting. During this change, the specific use case diagram and classdiagram/database diagram may be changed.
Is this considered to be Agile? (Even though he gave me the full 20 requirements from the start of the project)
Agile is sort of a big tent, but I would not apply that label to the process you've described. You are describing lots of upfront design work and a full specs up front. The schedule assumes all the req take the same amount of time to implement, thought you acknowledge that it could slip.
The primary agile feature I see is the tight (weekly) feedback loop with client.
I recommend trying on http://pm.stackexchange.com.
This is not considered as Scrum:
- Schedule is prefixed (5 sprints).
- Velocity is prefixed (4 use cases/sprint).
- No scrum ceremony is followed as such.
- All requirements are given upfront.
Please refer - https://www.scrumalliance.org/why-scrum/core-scrum-values-roles
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
In a user story mapping session, we should start by Identifying the different user types, then their goals or outcomes (represented on the map as activities), and the goals or outcomes of the company (represented on the map as versions or releases).
So for me it makes sense to try to deduct backbone tasks from user activities.
But in his book, Jeff Patton has an example (Everyday life) where he does the opposite, he first list all the tasks, then group them by higher goals or Activities.
So I am confused. From top goals to tasks, or from tasks to top goals ?
From top goals to tasks if you want to deliver fast.
Doing "As an HR manager I want to see turnover reports so I can better focus staff retention initiatives" first instead of starting with (e.g) a "Build CI/CD pipeline" task is the way to go.
That's because it eliminates waste and invites iterative problem solving: "At a minimum, what do we need for continuous integration/development so the HR manager can get her report?" is a great starting point. Go live on production with that, than beef up CI/CD as needed for the next story.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am not sure when you would break story into stories or into tasks.
Let's say you have a story that talks about bringing down a service, and to do that you have to analyze and depreciate 5 api where each one takes one week
How would you do that ?
1) break story into 5 stories and this way every story is less than a sprint and can be owned by someone (but cant be demoed)
2) break a story into tasks but then multiple people is working on a single story and one story is lasting more than sprint
Other?
Thank you
Let's say you have a story that talks about bringing down a service
Why are you doing that? Who is going to benefit from it?
That information will help you to create the story associated with the work item.
As a [person that benefits from this work] I want the service brought down so that [reason]
Now, once you have defined the user story you can then add sub-tasks to it that describe how the work will be done. e.g.
Sub-task1 = deprecate API X
Sub-task2 = deprecate API Y
From my point of view, the so-called story should be an epic. The epic should be split in multiple stories, each one tackling the decommissioning of a different service.
It is also equally important to split the stories into sub-tasks because you will most probably identify "hidden flaws". It will also allow you to bring more transparency in the process of completing the story. If the stories are similar from the tasking perspective, you can define the first one as a template for the other ones.
You can view this topic from a different perspective: your purpose is to remove some services that hinder your progress. After you put down one service, you are closer to the desired outcome of taking all the services down. And of course, after each decommissioned server you bring more value for you, your team, or the customer.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
In my agile development course, after gathering user requirements, I'm asked to write a plan (for developing an application) that is supposed to define project activities, milestones - iterations and deliverables. The plan is actually the work breakdown.
So what should the initial plan in an agile project look like? If I'm giving a plan of everything in advance (as the homework asks), isn't that the waterfall model. If each iteration in agile deals with the whole cycle of plan-do-check-act, then why do we need an initial plan?
You need an initial plan because somehow you have to decide how many people are going to work on the project and develop a budget. You can never know what your scope, time, and budget are all going to be, but generally one of these is going to be fixed. Figure out which is the most important and build a plan around that. Without this as a starting point, nobody is going to fund the project.
Build a project backlog with all of the known goals. Then pull out the biggest of the goals as key milestones. Generally, a client needs to see progress towards their desired feature set. A smart client will be prepared to adjust these as the project goes, but you can absolutely lay out a series of goals to give you targets for creating working software with each sprint.
You should read Planning Extreme Programming by Kent Beck. If you ignore the extreme part of the title you can easly adapt this to your agile methods.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
My current work involves working on a large number of bugs.
We normally (non TFS) would add these to an iteration backlog (grouped into Stories) after estimating and prioritising; then work through, mark actual effort.
I want to try and understand how I would work on these bugs using the TFS Agile template as intended. But am really struggling to find best practices and examples specifically for bugs for the TFS Agile template in TFS2010.
Cheers, Nick
I hear some parts in your question:
"Add these to an iteration backlog": you can use the iteration path of the work items. Best practice is to create an iteration called backlog.
"Grouped into Stories": In TFS 2010, the default traceablity is that on a User Story you define the Test Cases which validate the User Story. The Bugs are reported against the Test Cases.
"Estimating": You can use the Remaining work field for that
"Prioritsing": You can use the Stack Rank field
"Mark actual effort": Use the Completed work field
What we have been doing is:
Raising bug during testing by a tester.
During iteration planning we may decide to allocate X amount of time to fix outstanding bugs, so we creat a bug fixing story for that iteration of X story points.
Bugs are chosen that we think should be fixed within the iteration, a task is created for each bug along with a time estimate and any high level technical details. Note the task is created as a child of the story and also related to the bug.
The key is that bug work items are not developed against directly, a related task is.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Are user stories (typically used in agile development or test driven development) the same thing as events in Edward Yourdon's structured analysis methodology?
Events and user stories are related but not identical. A Yourdon event is any stimulus to the system that requires the system to respond, so, for example, a tick from an external clock could be an event. That might require a response, eg, by incrementing a counter, but it wouldn't necessarily lead to a result with direct business value to the customer, so wouldn't be a valid user story or use case.
A user story is a pattern for briefly describing a business, technical or other type of need.
For example:
As a risk analyst I would like to add references to the application page so that we can store the references with the application, where the verifications team can then use them to help improve our risk rate in our underwriting.
Then in your user story you would decompose the story describing what tasks will be needed to complete the "would like" with a "done" check point being the "so that".
Mike Cohn has a good article on User Stories and the advantage of them http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements
As far as Edward Yourdon's structured analysis methodology, I have to admit I'm not extremely familiar with it so I cant answer that part of your question.
That´s right, user stories and use cases from UML are rewrites of Yourdon´s events. They are just a reinvention of the wheel.