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
I'm a newbie to the Agile/TDD world and trying to get my head around some of the basics.
This is related to the way I should go about implementing user stories.
For e.g. lets assume I have below 2 user stories to start with for a hypothetical content management system:
Story 1:
As a Content Author
I need to be able to create News Articles
so that they can be used to attract users to the web site
Story 2:
As an Editor
I need to be able to view existing articles
so that I can review them to improve the quality
The way I would approach this is,
I would grab one of these user stories
break the I need to part of the user story into smaller pieces of tasks
Grab these tasks one by one and come up with Tests to cover the specific task
Implement tasks the TDD way
Area where my dilemma is about the As a part of the user story.
Specially in these examples they indirectly imply some Authentication,Authorization related requirments to me since the user stories mention about two user categories.
So my question is, whether I should have any tasks/tests that control Authentication/Authorization to the system to complete these user stories
Or should I only focus on the I need to part of the user stories in trying to implement the functionality, and wait for any user stories that specifically mention about Authentication,Authorization related requirments?
All your inputs are highly appreciated.
Cheers.
Worry not about the implications at this stage.
A user story should be:
I Independent The user story should be self contained, in a way that
there is no inherent dependency on another user story.
N Negotiable: User
stories, up until they are part of an iteration, can always be changed and
rewritten.
V Valuable: A user story must deliver value to the end user.
E Estimable: You must always be able
to estimate the size of a user story.
S Sized appropriately or Small: User
stories should not be so big as to become impossible to
plan / task / prioritise with a certain level of certainty.
T Testable: The user story or its related description
must provide the necessary information to make testing the development
possible.
[Source, Wikipedia]
If they haven't been wriiten yet, you can add the authorisation stories to your product backlog for the product owner to prioritise. The authorisation stories may be picked up by some other team, such as your network administration or similar, so concentrate on delivering the functionaility requested by the story that you are working on.
You should definitely focus on the I need to part and consider the As a and so that as some kind of context.
There are many loopholes in your stories. The underlying Authorization/Identification part is one, another one I see is that the so that I attract more visitors to my website is something you can't really test, so you should think again and find another one (probably something simple and not very different like so that I can put them on my website to attract more visitors). I believe that with that format the so that part should contain some rough idea of how you'll test your story.
Really I use something much less formal for my stories : a title, a short description and some explanation of how to demo. I also add some priority value (important for the product owner) and a rough estimate of the work amount. The most usefull part is probably the How to demo as it will help writing tests (after breaking the story if necessary, but I also prefer, if possible, keeping stories shorts to avoid the need to break them). Also I try not to break stories to tasks but to smaller stories. Task is often too much about how you will do something and you should focus on what result you want.
In your case, there will most certainly be other stories and one will be about authentication someday, but that should not stop you to code pages now. Just go on step by step, keep your stories simple (you have tests, refactoring later is easy) and you'll quickly get the feeling of what works for you.
You should have a look at the excellent Book Scrum and XP from Trenches and see how they do it.
The phrase
"As a Content Author
I need to be able to create News Articles
so that they can be used to attract users to the web site"
is not the story. It is a summary of the story that fits on a card or in a spreadsheet column and represents the story so you can remember which one you're talking about. The whole story is composed of three parts - Card, Conversation and Confirmation - and the part you need here is the conversation.
Talk to the user or the user representative in your team to find out what it really means.
As a part does not imply Authentication or Authorization. In the same way you can write a user story as:
As a new visitor ...
As a returning visitor ...
Does it mean that visitor has to be authenticated? What authorization vistor has? User stories should not include "hidden requirement". If you need authentication and authorization simply create user story for that.
As a part specifies type of user roles in your application. Each role has some special needs and requirements and uses application from different reason. You should try to collect roles before you start to write user stories.
A user story does not contain only description. It should contain additional information which are added in different phases of the process.
Description in defined format. You don't have to use As a ... I need ... so that ... if you think it doesn't fit your needs but you should use same format for all stories.
DoD - definition of done also known as acceptance criteria. This should be collected with description. User story without DoD is useless. DoD says developer additional information about user story. User story is completed only if it fulfills DoD. You can also create automated acceptance tests based on these criterias.
Priority set by customer - this will help you sort user stories by importance
Estimate - made by team. Estimate is not exact it should be based on comparison among user stories. Usual units of estimate is abstract story point or t-shirt size.
Also be aware that not every user story is decomposed to tasks directly. You can have big high level user story which will be first decomposed to smaller user stories. We call such user story Epic.
You could initially make the assumption that the user is authorized to make changes, then tackle the authorization as separate stories later on (when they become the most important items in your backlog).
This has the benefit of keeping the scope of your stories small so they are easier to work with, and also gets the initial stories in a potentially deployable state earlier on.
At the very least I'd spawn stories for:
authenticate user
signup Author / Editor ... or signup User, assign permissions
If no one knows how that'd be handle those at the story level, I'd talk to/grab the phone/initiate im and check with them. You can TDD your way at the lower level for the feature that you wan't to implement, but any test automation on end-to-end story should go through what the user does.
The thing with those stories is that you might be thinking in the underlying tasks, but from the user point of view you might end up finding that the client wanted more of a blog with openid/login with existing account feeling. Its agile after all, its the way it rolls / full communication instead of an all defined in a large analysis + design phase.
No point in dedicating a sec of thought to usernames/password/hashes/etc when that might not even relate to the project.
Whatever you do, keep it simple.
ps. its all an integral part of the story, it just happens to depend on other stories being in place.
Related
I have a main application. I have two typical human actors for the main application and written many user stories. But the main application needs a crawler, a scheduler and an admin application, in order to work. Are theses considered actors? I know that they are external to my main app and that they interact directly with it to achieve a goal, but they do not provide some obvious business value for non development team stakeholders.
I also have some very important specifications regarding how bad data are handled by the system and I can't think of anyone but the main application itself as an actor to describe these scenarios.
Some of the above are described in the functional and non functional requirements but I don't know if they can be described in user stories. Is this expected?
Should I just continue with my class design diagrams and sequence diagrams and document implementation details elsewhere?
Is this gap between analysis (functional, non functional requirements, user stories, conceptual diagrams...) and design (class diagrams, sequence diagrams ...) expected in many scenarios? If yes how do you bridge it (eg developer documentation, code comments)?
User stories start to slow me down because I know how to do this and can't comply with the terminology and I can't find a real world applications case studies.
I think user stories are slowing you down because they are difficult to master if you come from a waterfall "use case" background.
No, systems are not actors in user stories, because stories are about gaining value, and such stories have no value.
You say your system can't work without a crawler. If this is true, then you can't really have delivered anything, because a broken system has no value, clearly.
I'll assume you are working on some form of search engine. A search engine does not necessarily need an automated crawler in order to return results. It certainly needs some index.
In this case you could have one story
As a user I want to search the site so that ...,
to build the user front end against a fixed, unchanging, minimalist index, but then you could have another story (for the crawler)
As a user I want the search results to be fresh so that ...,
and then further stories
as a user I want to search PDFs so that ...",
to extend the crawler.
Note that none of these stories mentions the crawler. This is by-design. Stories should not design a system, just specify its purpose. This avoids premature architecture: if you are forced to require a component only through what its purpose is, them you may well discover that you can live with a simpler solution or that you can postpone its implementation significantly.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I'm starting a new project from scratch and have written User Stores to describe how a given user will interact with the system. But, I'm having trouble understanding how to break the first user story in to tasks without the first one becoming an epic.
For example, if I were building a car and the first user story said something like "As a driver, I would like to be able to change the direction of motion so that I don't hit things.", that would imply a user interface (steering wheel), but also motion (wheels) and everything necessary to link those together (axle, frame, linkage, etc...). In the end, that first user story always seems to represent about 40% of the project because it implies so much about the underlying architecture.
How do you break user stories down for a new project such that the first one doesn't become an epic representing your entire underlying architecture?
You might want to think of your story as a vertical slice of the system. A story may (and often will) touch components in all of the architectural layers of the system. You might therefore want to think of your tasks as the work needed to be done on each of the components that your story touches.
For example, Let's say you have a story like In order to easily be able to follow my friends' tweets, as a registered user, I want to automatically follow all of my gmail contacts that have twitter accounts.
In order to accomplish this, you will have to pass through the UI layer, service layer, persist some data in the data layer, and make an API call to twitter and gmail.
Your tasks might be:
Add an option to the menu
Add a new gmail authentication screen
Add a twitter authentication screen
Add a contact selection screen
Add a controller that calls into your service layer
Write a new service that does the work
Save contacts to the database
Modify your existing gmail API calling service to get contacts
Add a twitter API calling service to follow selected contacts
There: That's 9 possible tasks right there. Now, as a rule, you want your tasks to take roughly 1/2 a day to 2 days, with a bias towards one day (best practice, for sizing). Depending on the difficulty, you might break down these tasks further, or combine some if they are two easy (perhaps the two API calling services are so simple, you'd just have a modify external API services).
At any rate, this is a raw sketch of how to break the stories down.
EDIT:
In response to more question that I got on the subject of breaking stories into tasks, I wrote a blog post about it, and would like to share it here. I've elaborated on the steps needed to break the story. The link is here.
When we started projects under a Scrum management style, the first set of tasks was always broad, or as you describe it: epic. That's inevitable, the framework of any project is usually the most important, largest, and time-consuming portion, but it supports the rest of the project. In order to pare down the scale on overwhelming-ness of how much there is to do see if you can list the MOST essential parts. Then work on defining those tasks as the starting points. Therefore you have a few tasks as starting points for a broad beginning. Hope that makes sense!
A user story describe the what while a task is more about the how.
There is no perfect formula, just add any task that describe how the user story is going to be implemented, documented or tested.
Keep in mind that a task should be estimated in hours, so try to scale and detail the tasks accordingly.
If you feel that you have too many tasks for a story (even if you have 1-8 hours long tasks), then maybe you should consider rewriting your user story in the first place because it's probably too complex.
Good luck
The story that you implement at the beginning can be refined over time. You dont need to think that every story has to be the final version that the user is going to use.
For example, in a recent project we had to develop an application which involved indexing various websites, and matching them against filters created by users, and finally alerting the user of matches (thing of it as google alert on steroids).
If you look at it from one perspective, there is only one story - "As a user I want to get alerts from matching pages". But look at it from another perspective of "what are the risks we want to mitigate". The first risk was that users wouldn't get relevant or better hits compared to google alerts. The second risk was in learning the technology to build this.
So our first user story was simply "As a user I want relevant hits", then we built just the hit matching algorithm on a hardcoded set of pages and hardcoded filters for some early users and got their feedback.
There might actually be a bit of back and forth here with multiple smaller stories to capture learning like "As a user I want more priority to be given to matches in the URL" etc.. these stories comes from the feedback as we iterate over what the early users consider "relevant hits".
Next, we broadened it to "As a user I want hits from specific websites" and we built the indexing architecture to crawl user specified sites and do hit matching on that.
The third story was "As a user I want to define my own filters", and we built this part of the system.
In this way we were able to build up the architecture piece by piece. Through most of the initial part, only early users could use the system, and many pieces of data were hardcoded etc.
After a point, early users could use the system completely. Then we added stories for allowing new users to register and opened it up to the public.
To cut a long story short, the story you implement first could implement only a small part of the final story, hardcoding and scaffolding everything else. And then you can iterate on it over time till you get the story that you might actually release to the public.
I've come to a crossroads with this issue in the past. User stories are supposed to be isolated so you can do them without any other stories, in whatever order, etc. But I found making that happen just made everything more complicated. To me this fell under the "Individuals and interactions over processes and tools" part of the agile manifesto - or at least my interpretation of it.
The ultimate goal is ship. And to ship you have to build, and to build you have to stop futzing with scrum and just get stuff done and make sure you track it.
So what we did was break a cardinal rule of stories and we made some tech stories like "create a preliminary schema". We also declared that some stories were dependent on others, and noted that on the back of the story card.
In the end I felt this type of story was few and far between, and the difficulty of the alternative justified the exception.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I am attempting to manage my projects a little better so I am looking at attempting to apply some of (eventually all) the features of scrum.
Looking at user stories specifically the high level format seems to be:
As a User I can Feature Description
or
Artifact is Doing Something
How would I write "Upgrade the Database"?
Is it simply Upgrade the Database?
I think I am being thrown off as there is no specific actor/customer and that the customer is the IT department.
AS A [person/role]
I NEED TO [do something]
SO THAT [provides business value].
For your example a user story might look like this:
AS A user of the XYZ application
I NEED TO get reports of ABC faster
SO THAT we can increase our conversion rates.
ACCEPTANCE CRITERIA - The database reliably completes transactions on average in 2 seconds.
I've added an acceptance criteria because without this you will never know when the job is done. Now at this point, you have a business case for upgrading the database. This story would be decomposed into a story where the role is the IT department or DBA, like so:
AS AN administrator for the database server
I NEED TO upgrade to the latest version of FancyDB 11.7
SO THAT we can improve the average transaction time for XYZ users to 2 seconds.
ACCEPTANCE CRITERIA - the new version starts successfully, the XYZ developers sign off on the test installation of 11.7, data migration is successful, we have cut over to the new db
When story decomposition is added to your box of tools, the story must start from where the user is a real part of the business, and the "so that" leads to a real business value. Then decompose the story into one or more stories in which internal users do things "so that" real users get the benefits in need.
Here are a couple of articles that talk about Story Decomposition:
http://jpattonassociates.com/the_shrinking_story/
http://old.cognitive-edge.com/wp-content/uploads/1999/11/56-1999-11-Paradox-of-Story.pdf
Scrum is not very prescriptive and there is nothing in Scrum that forces you to use User Stories for your Product Backlog Items (PBIs). You can definitely do Scrum without capturing requirements/features as user stories, user stories are just one way to do it. Actually, stories do work for many teams, especially web development teams, but this doesn't mean that they work in all cases and on every project (many projects are web development but not all, like in your case). There is no consensus about using stories.
That said, the recommended template for User Stories is actually As a <role>, I want to <action> so that <benefits>. I don't mean to be picky but, if you choose to use stories, I'd warmly suggest to use it as is, without removing any part. First, using a role do help (a same user/person can have several roles) to discover stories. Then specifying the benefits is really important to expose the business value of a story in order to prioritize them well. Regarding the value, you should think of it as end-user/customer ("put on customer glasses" --Mary Poppendieck). It is really not always that easy to express the benefits, but some tools might help and my preferred one is the 5 whys (which is used for root cause analysis).
In your case, this could lead to something like: As the IT department, I want the database to be upgraded so that users can benefits from the latest features of the application and [do a better job|have a better user experience] (not very satisfying though, use the 5 whys).
But personally I don't find that user stories are the best medium for technical tasks even if it is clearly possible to use them and if they have their strengths. Theoretically, stories capture the essence, not the details and should be a support for the discussion. I may be wrong but I don't find that technical tasks offer much room for discussion and creativity. So, depending on who will read them, what the should convey, I might use them or not. Another option could be to mix stories with another formalism for your PBIs. As I said, the point is not to use stories, the point is to have a list of prioritized and estimated items.
Upgrade the database may be one of the tasks involved in implementing another story that brings direct value to the user, for example I as a user can add a new foo to my bar.
If adding a foo to a bar requires a database upgrade behind the scenes, then you would include that work in implementing that user story.
User stories are worded this way to help ensure that any work directly benefits the end user in some way.
This gets to the forefront of why user stories are so great.
What benefit does upgrading your database give to the end user? None? Then don't spend the time and money doing it. Spend that time and money providing something that will give value to your end user.
If it does? Then think about it the other way. Maybe you can only implement a new feature when you have version x of your database software? In the dependency of the story, you could mention that database upgrade required to provide this feature.
tl;dr Don't just upgrade for the sake of it. Make sure upgrading adds tangible value to your customers.
Generally, technical tasks in the PB are frowned upon because they very rarely directly deliver business value to the customer. That's why User Stories are popular, because they force you to think about the business value of the story, and who it's being delivered to.
So, why are you upgrading the database? Can you identify business value in upgrading it, and why should the Product Owner agree to let you upgrade the database instead of building new features?
Is it because of a new feature that will make it possible or make it easier to do something in your application? In that case, that something should be the PB item, and the database upgrade should be a task within that story. If you already have stories on the PB that would benefit from the upgrade, then you should increase the estimates for one or more of those stories, and add the upgrade as a technical task to the story.
Is it because the vendor of the database is cutting off an old version from support? In that case you could have the upgrade as the story; something like, "As the department manager, I want to be sure that we have support for all of the software so that the continuity of the business isn't at risk if something goes wrong". Even that's pushing it, though. Generally, this kind of reason isn't really part of a project, unless the project has been going on so long the system software goes off support.
Is it for performance? Then the story should be about some aspect of the performance of the application that needs to be improved to deliver business value. Something like, "As a CSR I need to be able to retrieve customer information in a reasonable time so that customers on the phone are satisfied with our service". Then the upgrade becomes a task under that story.
Is it for some totally technical reason? If you can't identify how the upgrade is going to deliver business value, then why would you do it? Why would the Product Owner select it for a Sprint?
It's simply "Upgrade the Database" or maybe "When the new version is installed, there must be a way to migrate the existing database". If you already know more details about this step, then include them. But the story mostly exists to make sure something isn't forgotten; it's not to be detailed.
Later, when you get to implement this story, you can flesh it out (which tables, do we need one or more backups, is there a fall back scenario, etc).
OTOH, if the project is more complex, this can become a "tag", like a post-it notice which must be attached to many stories. That means you must include this as a "sub story" to all stories which change the database. As you can see, these "project-spanning stories" are a bit hard to track with agile methods.
Infrastructure stories do not need to follow the prescribed story template. Just write down what needs to be done and estimate accordingly
How about:
As the application support person I want to be on the latest version of database because it is more reliable / more secure / whatever.
You could even phrase refactoring like that:
As the application developer I want all the data classes in one module so that I can add new fields to the app very quickly.
Who benefits
What you want to do
What the benefit is
Ideally you don't want all the stories to have 1 be developers, but a few make sense (sharpening your ax instead of cutting down trees and all that).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
The question is quite generic. What are the points that should be kept in mind to identify a valid use case? How to approach a use case?
A use case identifies, with specificity, a task or goal that users will be able to accomplish using a program. It should be written in terms that users can understand.
Wikipedia's description is overly formal. I'll dig through my other texts shortly.
In contrast, the original wiki's article is much more accessible.
An early article by Alastair Cockburn, cited positively by The Pragmatic Programmer, contains a good template.
This question, from just a few days ago, is very closely related, but slightly more specific.
The definition of use case is simple:
An actor's interactions with a system to create something of business value.
More formally:
a sequence of transactions performed
by a system that yield a measurable
set of values for a particular actor.
They're intended to be very simple: Actor, Interaction, Value. You can add some details, but not too many.
Using use cases is easy. Read this: http://www.gatherspace.com/static/use_case_example.html
The biggest mistake is overlooking the interaction between actor and system. A use case is not a place to write down long, detailed, technical algorithm designs. A use case is where an actor does something.
People interact with systems so they can take actions (place orders, approve billing, reject an insurance claim, etc.) To take an action, they first make a decision. To make a decision, they need information
Information
Decision
Action
These are the ingredients in the "Interaction" portion of a use case.
A valid use case could describe:
intended audience / user
pre-requisites (ie must have logged in, etc)
expected outcome(s)
possible points of failure
workflow of user
From Guideline: Identify and Outline Actors and Use Cases by the Eclipse people:
Identifying actors
Find the external entities with which
the system under development must
interact. Candidates include groups of
users who will require help from the
system to perform their tasks and run
the system's primary or secondary
functions, as well as external
hardware, software, and other systems.
Define each candidate actor by naming
it and writing a brief description.
Includes the actor's area of
responsibility and the goals that the
actor will attempt to accomplish when
using the system. Eliminate actor
candidates who do not have any goals.
These questions are useful in
identifying actors:
Who will supply, use, or remove
information from the system?
Who will
use the system?
Who is interested in a
certain feature or service provided by
the system?
Who will support and
maintain the system?
What are the
system's external resources?
What
other systems will need to interact
with the system under development?
Review the list of stakeholders that
you captured in the Vision statement.
Not all stakeholders will be actors
(meaning, they will not all interact
directly with the system under
development), but this list of
stakeholders is useful for identifying
candidates for actors.
Identifying use cases
The best way to find use cases is to
consider what each actor requires of
the system. For each actor, human or
not, ask:
What are the goals that the actor will
attempt to accomplish with the system?
What are the primary tasks that the
actor wants the system to perform?
Will the actor create, store, change,
remove, or read data in the system?
Will the actor need to inform the
system about sudden external changes?
Does the actor need to be informed
about certain occurrences, such as
unavailability of a network resource,
in the system?
Will the actor perform
a system startup or shutdown?
Understanding how the target
organization works and how this
information system might be
incorporated into existing operations
gives an idea of system's
surroundings. That information can
reveal other use case candidates.
Give a unique name and brief
description that clearly describes the
goals for each use case. If the
candidate use case does not have
goals, ask yourself why it exists, and
then either identify a goal or
eliminate the use case.
Outlining Use Cases
Without going into details, write a
first draft of the flow of events of
the use cases identified as being of
high priority. Initially, write a
simple step-by-step description of the
basic flow of the use case. The
step-by-step description is a simple
ordered list of interactions between
the actor and the system. For example,
the description of the basic flow of
the Withdraw Cash use case of an
automated teller machine (ATM) would
be something like this:
The customer inserts a bank card.
The system validates the card and prompts
the person to enter a personal
identification number (PIN).
The customer enters a PIN.
The system
validates the PIN and prompts the
customer to select an action.
The customer selects Withdraw Cash.
The system prompts the customer to choose
which account.
The customer selects
the checking account.
The system
prompts for an amount.
The customer
enters the amount to withdraw.
The
system validates the amount (assuming
sufficient funds), and then issues
cash and receipt.
The customer takes the cash and receipt, and then
retrieves the bank card.
The use case ends.
As you create this step-by-step
description of the basic flow of
events, you can discover alternative
and exceptional flows. For example,
what happens if the customer enters an
invalid PIN? Record the name and a
brief description of each alternate
flow that you identified.
Representing relationships between
actors and use cases
The relationship between actors and
use cases can be captured, or
documented. There are several ways to
do this. If you are using a use-case
model on the project, you can create
use-case diagrams to show how actors
and use cases relate to each other.
Refer to Guideline: Use-Case
Model for more information.
If you are not using a use-case model
for the project, make sure that each
use case identifies the associated
primary and secondary actors.
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
Say we are creating Acme CMS. This CMS web application will allow you to create an unlimited number of categories with sub-categories (unlimited depth), and each category can have 0+ content pages associated with it.
So this project, at a high level will have:
Front End
1. index page
2. category page with list of content pages
3. content page
Admin Control Panel
1. categories (add/update/delete)
2. pages (add/update/delete/)
Schema design
1. tables
2. stored procedures
3. data access layer
Questions:
I am using a bug tracker and Wiki, so how should I break this project down?
I am thinking of breaking each section (front end/ admin panel) down into individual pages, then writing simple user stories for each page (or theme).
When I have the user stories completed, I will then create a list of cases in my bug tracker representing features that I have to develop, along with an estimate for each one.
Am I breaking down this project properly? Any major gaps in planning that will make this project fail (in theory anyway!)
Please provide a detailed answer, maybe a general idea of what I should do, with a detailed example explaining it and why etc.
"I am thinking of breaking each section (front end/ admin panel) down into individual pages, then writing simple user stories for each page (or theme)."
Pages don't have stories. Users have stories. Pages are a thing you build to implement the user story.
The Theme -- if there is one for something this small -- is "managing content". Perhaps there are two themes: the collection of stories about writing/editing and the story(s) around browsing/reading.
Some users ('editors'?) want to create, organize, update and remove content so they can something [the question doesn't say]. You force them to use web pages because it's better - cheaper - faster than 5x8 cards and markers.
Some users ('readers'?) want to examine content and navigate so they can -- who knows? -- be happier and more productive at something. You force them to use web pages because it's somehow better than 5x8 cards held to a whiteboard with magnets.
You have stories about the theme of creating and managing content.
"then create a list of cases in my bug tracker representing features that I have to develop, along with an estimate for each one"
Right. And the features have to begin with data model first, then presentation in some useful form. Perhaps on pages. Indeed, once you have a model that satisfies the use cases in a broad way, you can fine-tune the presentation to make the model more usable.
"business layer & presentation is what I need to detail"
Model == business layer. They're the same thing.
Pages == presentation. Note. This is last. Once you have use cases and a model that supports those use cases, you can present your stuff to people so they can interact with the model.
As far as I can see you've got a few glaring gaps in your design, part of the features is implied (linking of categories and pages) and some are left out altogether (login for administrators, user management, preview etc). These are going to make up about half of your small application, and you better include them into the initial outline. Perhaps you may want to take a more systematic approach to designing the CMS. And there are at least three general routes you could take:
Design a domain model first, and then design business layer, then UI and data model.
Start with data model and build business layer and UI on top of it.
Model the UI first, then everything else.
Regardless of which path you would prefer to take (or combination of) there are some general guidelines:
Start with a big picture of work you want to automate. This is called “work scope”. “Big picture” here can be meant quite literally and although it can be a just a story describing the process, it is best to visualise using a rich picture that includes actions, artefacts, other applications, users etc. As for the “big” part of the equation the picture needs to encompass more than the intended product, be bigger than the segment of work you want to automate.
Then outline what specific work you want your product to take care of. This is usually referred to as “product scope”.
Make a list of user roles (or profiles) for your application, list of inputs and outputs, list of external interfaces.
Now you may want to start writing some user stories. You’ll need at least one per user profile, since you need to provide an illustration of all user perspectives.
At this point there going to be just enough information at your disposal to start a more precise modelling of the problem using either domain model, or UI model or data model, whichever you fancy or feel more comfortable with.
All of the steps are very much iterative. Once you understand a bit more about the application, its wider context and have a list of features that need to be implemented to meet the requirements you’d be in the position to give some very rough estimates and then go through a prioritisation process.
Needless to say that this is just a simplified framework and many software developers would take a different approach to designing an app, depending on their skills, needs, preferences etc. But it could be a good starting point to a more systematic evaluation of the problem you want to solve.
The "unlimited" part is broken... even GMail has an upper limit...
Edit: Although my answer got downvoted I think it is right. As soon as you talk with non-programmers the "unlimite" parts become very dangerous, and will likely stab you in the back. Also you can't really have a scalable data schema for unlimited nesting... but that should be obvious.