Goals: what are all the goals of the project - business and otherwise. This will allow you to determine what features are mandatory.
Roles:who is going to use the website admins, visitors, members? Have different users different views of the same data on the business site?
Features:what are the basic interaction on the website? For instance: Users: registration, using the forums and blogging. Admins: managing the web content.
The stories are different from the features because it depicts a single thread of interaction from a specific visitor’s perspective. It is general to express the stories inform "As a ____ I need to ____ so that _____." This enables you to answer 3 different questions.
For example: "As an administrator, I need to ban visitors from the forum so that I can improve the quality of user-submitted content on the website.
Estimation is a huge topic in itself, but the general idea is to combine a particular level of effort with each and every story.
The commonly used scales are 0/1/2/3/4, 0/1/2/4/8. But this is not mandatory, select something and stay with it.
Do not get obsessed with the exactness of the estimates. Many things affect how long it takes you to complete a story so minor differences in the story complexity lead to get lot noise.
Your aim here is to distinguish things that are less in effort such as stories that will result in you building a simple model by using a REST controller from stories that are high in efforts like enables interface your app with a challenging 3rd party API or a story that will need you to make use of a technology that you are not very familiar. Note down the estimate on each card.
To tackle the stories you can rearrange the cards.
The product owner only have alright to make this decision. There are more things that go into prioritization like user testing, deadlines, business value and much more. Estimation can have more to do with prioritization as it lightens the opportunity cost. The product owner may really need that elaborate Admin Dashboard is it worth it to spend a month on just this feature because all the stories to make that work total 40 points. The product owner may still need the story, is there any story that does not suit the less strong product to release? If so then you can move them down. As quickly as possible complete the functioning application so that you can place it in front of audiences. At the moment, we basically move the cards into Pivotal Tracker but we know many people who choose paper and pen.
Start with Cucumber write a Cucumber feature that covers the visitor’s interaction with the website from start to end. And also define the steps that are undefined because you come to them & when your first failure is hit then you know that there is a behavior that you like that your application does not have. This can take place very faster at first as your blank application does not have such behavior.
Proceed to Rspec write the test behavior for the wish that you had.
Write the code to enable the spec pass. This is going to take you throughout your app from routing to models, to UI, to DB schema, to the controller. You'll gear these codes in the order your tests control you too.
This is the perfect time to repair the CSS styling presuming you have the design done.
Do you accept the story? Does the story do what you needed to do? If not then you want to go back and enables it must work the manner it was actually to. Developing the Cucumber tests in advance allow to prevent this from occurring.
All your test cases pass? If you break the build then you are required to fix what you broke.
Suppose if you are working alone then it may be useful to have someone else to do the acceptance for you.
This is all how we do projects. This does not mean the only way to do it, but this approach is a common way to do projects. Hope, here had a useful discussion around the value of agile estimation or about the specific technologies such as Cucumber, Steak, RSpec, and so on. Our workflow is:
© Copyright 2018