Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm curious as to what other people use for physical Kanban/Scrum boards in their companies. I appreciate that because of sensitive business information you may not be able to provide a photo of the board. I"m looking at to find out what does your board looks like, and how you organize user stories and tasks as they move through a typical sprint/iteration?
Typically I've worked in a places that organize the board as follows with each
User Story | Todo | In Progress | Ready for QA | Done |
UC-001 | Domain Object, Service | DAO(Bob) | | |
UC-002 | Payment UI Screen | | Payment Srv (Don)| |
UC-003 | | | UC-003 | |
| | | | UC-004 |
| | | | UC-005 |
So to summarise:
A task for UC-001 is in progress by one member of the team (Bob). A list of tasks for other people to pick up are waiting in the Todo column, but this can be picked up by another member of the team who co-ordinate with Bob to get the work done.
For UC-002 the payment service task was completed and an automated test harness was completed for QA allowing them to test the service without a UI. If the test fails a bug is raised and moved along with the Payment Service task back into the QA phase
All the tasks for UC-003 was completed and moved to Ready for QA.
All the tasks for Uc-004 and UC-005 were complete so the user story was moved to Done.
This works as a tangible white board that involves people interacting with each of the tasks/user stories (represented as post it notes). An electronic version is created prior to the sprint/iteration and is only updated at the end of the sprint/iteration corresponding to the current situation. Comments and criticism are welcomed : )
We use something inspired by the famous Scrum and XP from the Trenches from Henrik Kniberg, the columns being adapted depending on the context (often: TODO, ON GOING, TO BE TESTED, DONE):
alt text http://blog.realcoderscoding.com/wp-content/uploads/2008/09/hk.png
Product Backlog Items (PBIs) are printed as "physical cards" (A5 format) for the Sprint Planning Meeting (at least the most important). Once the team has picked up PBIs for the next iteration, items are break down into tasks/activities (on sticky notes). After the meeting, everything goes on the Scrum Board and I suggest to use tape or thumbtacks or magnets. PBIs are ordered by importance, most important at the top of the board, less important at the bottom. The team should work on the most important item first until it gets done. First, activity post-its move from the left to the right. Then, the PBI jumps to Done. Unexpected tasks are added to an "Unplanned items" zone (to take them into account in the burndown chart). Future PBIs stay visible in a "Next" zone (if all items are completed during the iteration, we pick a new one from there). Pretty simple.
These practices allow to detect smells visually, for example:
stucked tasks (i.e. tasks that are not moving) that show a potential impediment
team doing things in the wrong order and not focusing on top-priority items, like on your sample :)
too much work in progress, nothing done
unplanned items that are killing a sprint
Works great.
If you are looking for more "kanban oriented" stuff, maybe have a look at Kanban vs Scrum, One day in Kanban Land and Kanban and Scrum - a practical guide from the same Henrik Kniberg. Great stuff too.
And, for more pictures, give Google Images a try with scrum+board, kanban, scrumban, scrum+kanban.
Here is our Kanban Board that we use at TargetProcess. We do not work on Tasks level, just on User Stories and Bugs level. Sometimes we create tasks, but they are not tracked explicitly on the board.
We do not estimate User Stories and Bugs, but try to split Stories into smaller (with mixed success). Columns are self-explanatory. We accumulate items in Tested column, then create a branch , smoke test it and release new build. Usually we release new build every two weeks.
Also the board shows developers and testers load and classes of services via color coding.
UPD. Now we have several small teams and use a single board to track progress of all teams in http://www.targetprocess.com/3
Scrum / Extreme programming storyboard.
http://www.flickr.com/photos/dafydd_ll_rees/4138686549/
Work appears on the second-from left colum, and progresses across the board through different stages of completeness.
Column names: Not Started, Just Started, Half-Way, Almost Done, Ready for Showcase (passed QA)
The first row is specially reserved for bug fixing - like a fixed, priority for clearing bugs.
The Simpsons characters represent each member of the team. They're moved around so we can see who's working on what.
I suggest you to take a look on Eylean board. http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_campaign=geffort
it can fit all your needs because of intuitive interface, statistics, dashboard. Also it fits any process and the most important thing it is very easy to use. This board allows you to represent several projects on one board using rows. All the rows may be visible at a time or you can remove selected ones from the scope.Another solution may be task grouping and filtering by categories - then all the tasks can be represented on one board and row, but attached to different categories.
In practice the organisation of the work-in-progress board is best left for the team to determine depending on your circumstances and environment. (Agile == selfmanagement.)
That said, here's what we did in my previous team, part of a 300+ developer effort that was relatively new to Agile and Scum:
We had two boards - one with index cards for forthcoming stories so we could tell what was coming up, and one with the current sprint's work. Our columns on the current sprint board were simply
Not Started
Under Development
Dev Done
In QA
Complete ("Done Done")
and a box in the corner for Blocked.
A post-it note represented each story.
Developers each had a little magnet which they used at the standup each morning to signify who was working on what. Our team was quite big (~ 12 at one point) so this really helped figure out who was paired with whom.
We didn't bother with an electronic version (no point), although our Product Owner did have a Scrumworks system that he needed to keep up to date. We kept as far away from that as we could!
I'm pretty keen on Lean/Kanban and we've been iterating on our process for a while, initially through a customized workflow in JIRA, but that's not exactly frictionless given the admin complexity in the enterprise version. We've now expanded our use of a whiteboard and have decided to iterate our process using the whiteboard for a while before re-codifying it in JIRA. Here is an example of our layout:
We are 6 developers
When a story is in dev, it's on a dev's desk. Likewise with being reviewed, being QA'd, etc. This means every card on the board represents and actionable item, and also provides a decently accurate snapshot of iteration progress. The rule is that only in exceptional circumstances do you have more than one card on your desk.
We've agreed not to have more than two cards "pile-up" in the Awaiting Review column. This maintains a degree of "flow".
Backlog | Awaiting Dev | Awaiting Review | Awaiting Design | Awaiting Deployment | Awaiting QA | Done |
Story11 | Story2 | Story9 | Story 6 | Story1 | Story9 |
Story3 | Story7 | | | | Story12 |
Story8 | Story10 | | | | |
| | | | | |
| | | | | |
This is pretty close to mapping the value stream except for the awaiting deployment part, which is a hack to fix the problem where QA can't QA an item until we've deployed it on their server - we deploy 3/4 times during a 2 week iteration.
One thing I have noticed from mapping the value stream on an "information radiator" is that it does magically focus people on the actual value-add work that needs to be done, and that seems to up the pace of business-value development and keep up momentum.
Hope that helps!
We're experimenting with a couple of different board structures across a few different projects that we're running. One project has the most basic structure we can use:
| (Sprint) Backlog | In Progress | Done |
As much as possible, we try to have a single post-it to represent both the Dev and QA activities for a story.
The above structure has seemed to work ok for the developers on the project, but the QA members have struggled to know when a story had the development work complete such that they could execute their tests for that story. We found ourselves moving the stories to the "far side" of the In Progress section to indicate that the Dev work was done and that QA could pick up that story. This very quickly became quite unmanageable as the In Progress section filled up.
This led to the second iteration of board structure for another project which is:
| (Sprint) Backlog | In Progress | Ready for Test | Done |
The newly added section Ready for Test essentially became a formal section of the board that was previously the "far side" of the In Progress section. On the surface of it, this should have made things clearer for the QA members, but this still caused some confusion as people had different interpretations of what Ready for Test meant (I'll not bore you with the different interpretations here).
This has then led to the latest iteration of board structure we're using on another project:
| (Sprint) Backlog | Dev in Progress | Dev Done | QA in Progress | Done |
This is certainly quite a far way from the simple Backlog, In Progress and Done sections of the first iteration, but this appears to be working well for the team. They have a clear understanding of what it means to move a story through various sections of the board and for any one story, it gives a clear picture of where in the life cycle that particular story is. We've only been using this structure since the start of the current sprint (we're 9 days into a 10 day sprint), so we'll be exploring this structure in more detail in our retrospective tomorrow. Not perfect I'm sure, but if it continues to work for the team that is piloting it, we'll try to roll it out across other teams in our organisation.
Our whiteboard is broken down into these columns:
Story, Not Started, Req/Des/Dev*, Peer Review, QA, Done
The highest priority stories go from top to bottom.
Each story can have multiple tasks so we use a big postit for the story and smaller ones for the tasks. Tasks move from left to right. Every day we check to make sure we're working on the highest priority stories.
We use a sticky white tab on each task where the person working on it puts their initials. When they're done and move it along a new white tab is placed over the old one to show it's available to anyone to pick up. When all the tasks are done, the story is moved to the Done column also and at the standup, all Done work is tallied up and moved up the board to make room at the bottom for more stories.
We also have colored tabs for the stories and tasks to indicate blockages to progress (blue indicating a blockage from another team, red requesting scrum master assistance). We talk about the roadblocks at each standup.
We can see when there is too many tasks in one particular column and shift emphasis to get more to Done. We deliberately added the review column to emphasize that the work needed reviewed by someone other than the person doing it before it got to QA.
*Requirements/Design/Development
Ours looks fairly similar. Each developer has a column and we have rows for 'Done', 'In Testing', 'Work in Progress', 'Backlog'.
And we use actual post-it style notes that we physically move as it goes through each phase.
Personally, I find the system to be lacking...
Manually moving post-its gets to be a pain after a while. Our QA team mostly manages the ticket moving - and it's a constant effort to keep them synched with TFS.
The post-its can really only be moved so many times before they aren't sticky anymore. If a ticket is sent-back from testing and placed into 'In Progress' and then moved back to testing, etc, etc...it doesn't take much for it to end up on the floor.
Sometimes, the sheer volume of notes is overwhelming. Notes have to be stacked to be even remotely visible - we layer them such that we can see each notes unique identifier (as best as we can)...but then you've got a stack of 10 notes and you need to get the 5th out of the stack and you are rapidly contributing to the decrease in stickiness that will end with the notes on the floor.
When the tickets do end up on the floor it's reasonably annoying to find out where they should go. Was that Developer A's ticket? Or B? And was it in Testing? Or was it done? Let's go back into TFS, look up those tickets and then move the post-its accordingly.
Personally, I don't think post-it notes are the appropriate tool here. There are a handful of digital tools that make this sort of thing completely trouble free. We use Team foundation server - and I've seen a couple of really great, robust, free, and even open source tools that will interface with Team foundation server and manage all of that for you, in real time.
http://www.telerik.com/community/labs/tfs-work-item-manager-and-tfs-project-dashboard.aspx
Our boards tend to evolve overtime as we progress as a team. I tend to favour physical card boards if you have a collocated to team as it encourages better face to face communication generally from my experience. Obviously there is more overhead, but it's worth it to get the team working together. Another advantage I have seen with physical boards is that it helps with business engagement. Remote stakeholders can't just sign in and see progress within the current sprint and take things out of context as sometimes cards don't tell the full story. They have to have a conversation and come to the board which can be beneficial as things can get explained and it also means that they can be encouraged to help resolve with impediments. However this is not exclusive to physical boards but it helps.
As mentioned our boards evolve overtime with the teams needs. Often we start with textbook scrum, but encourage continuous improvement and usually end up with a scrumban solution. These changes are reflected by visualising the new workflow through the boards. I recently wrote a post on our latest change if your interested have a look at our hourglass scrum / Kanban board
I think the team should get involved in making the boards as it helps the team understand the workflow and not become silo's. Also if the team have had a hand in making the board they police their own processes better which helps with self organisation as it's a product they have had input to.
We went with following board structure in our company.
Backlog | Next sprint | Current sprint | Done
Buffer | Working
Lanes are assigned to specific members. Each member has different job at our office so the tasks vary. We add what we have to work on to our Backlog, then move it into Next Sprint if it approaches the deadline. Blocked green tasks are used for continuous tasks that have to be worked on daily. Red cards indicate importance of the task and have to be finished as soon as possible.
Our board allows us to collaborate freely and add tasks to each others swimlanes if we need something to be done by different department.
We use KanbanTool (Kanbantool.com) to visualize our workflow and manage projects. It's really intuitive and easy to use. Our team communication has improved tremendously.
Related
I'm a newbie to cucumber. I've the following scenario that I want to code in cucumber:
Feature: Withdraw Fixed Amount
The "Withdraw Cash" menu contains several fixed amounts to
speed up transactions for users.
Scenario Outline: Withdraw fixed amount
Given I have <Balance> in my account
When I choose to withdraw the fixed amount of <Withdrawal>
Then I should receive <Received> cash
And the balance of my account should be <Remaining>
Examples:
| Balance | Withdrawal | Received | Remaining |
| $500 | $50 | $50 | $450 |
| $500 | $100 | $100 | $400 |
I 'd like to read the data (Examples:)from a file like this:
$500;$50;;$50;$450
$500;$100;$100;$400
I'm not sure if I can read data from cucumber's feature file or in the step definitions. Could someone please shed some lights on this? Many thanks!
No it's not possible to 'generate' scenarios in Cucumber. Each row in your example table runs as an individual scenario, and Cucumber must know up-front which scenarios are to be run.
That said, there are 2 possibilities, I'd consider both to be quite unattractive:
Write the entire scenario in code in a single step def e.g.:
Scenario: Withdraw fixed amount
Given withdrawing should work correctly
#steps.rb
Given /^withdrawing should work correctly$/ do
# Read values from file
# For each row in the file, do everything the scenario would do
end
This works but will have the serious drawback of revealing nothing about the behaviour of the system through the Gherkin feature.
Code gen the feature file. Use a templating language such as ERB to transform a feature file, inserting whatever example rows are necessary, as a task which occurs before running Cucumber. Effective, but at the cost of a LOT of complexity.
In both situations you're removing the numbers from the feature file, which immediately negates its function as a central source of documentation, readers would have to refer back to the 'numbers' file in order to figure out the actual behaviour of the system.
What you requested is overkill. Examples are here to help you identify possible cases in clear format, but not for mass data handling.
Each row in Examples should be meaningful otherwise you are wasting resources.
For example. With $100 balance, withdrawal of $20 should leave $80. But $20 may be a hardcoded number, so you need one more case to verify that, say withdrawing $30.
The ATM system may have a daily withdrawal limitation of $1000. So, if you ask for $1200, the system should only give you $1000. You need another row to test that.
Every case above is meaningful. And I don't think there are so much cases that you need a CSV file to handle it. Manual typing is good enough.
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 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.
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 3 years ago.
Improve this question
I currently work in a small business (15-20 employees, 5 programmers) where most projects are custom built CMS and a few web applications products.
Since I started working there, I have worked on many projects, but specifications for each project vary a lot. Sometimes we get a little detail, a Word document telling what the client wants, and what we are suggesting (suggested form fields, a short description of display, etc.). Sometimes almost nothing except "do what you think is the best approach for this project/module/request".
My question to you guys, who might work in different kind of businesses, is: How (huge pile of paper? Word docs? Visios?) and what kind of information do you get from your superiors, managers, teamates when starting a project (plenty of analysis, drawings, etc.)? How much detail do you get on this?
Hope my question is clear enough, thank you.
Specs..that's kind of funny...how about never :(.
Seriously a lot of companies assume specs aren't needed, its absolutely unacceptable but this is how it is in a LOT of companies. They assume a one liner and the programmer knows what the program should do, the inputs / outputs and so on.
Unfortunately in my case I have to actually help write the specs..and Im the programmer :(.
I mostly get a lot of verbal direction and I use a voice recorder to record the conversation and transcribe it when I am done. I write my own specs from my customers' words.
Then, as a good consultant should, I take the writeup back to the customer and verify it, and get a signature and build it, and they live happily every after! (no they dont, they change their mind a 100 times)
It can vary depending on what group the work falls under:
Support request - If the change will take a short period of time and is fixing something broken, there is this group. This could be as simple as, "Add Bob to the list of authorized users for that ancient form" where the form is something written years ago and aside from adding and removing users, it isn't touched for fear of breaking things.
Service Advisory Committee request - Items that are up to a few days are in this group as these are kind of like mini-projects as the request may be to create a new form or portal for a group. This could be upgrading some 3rd party software where we have some customizations that make the upgrade not necessarily a simple thing for Operations to do.
Project - In this case there are usually a few Word documents and/or e-mail threads that help nail down requirements in terms of scope, budget, and time. These can take months though there is something to be said for having a prototype to change rather than creating the initial prototype to tell if requirements are really met or not. Course my current project is over a year old, still has a few more months to the timeline and already has a successor coming after it is done,i.e. there is a Phase II to go after Phase I.
Uber project - These merit their own group of documentation and are the million dollar, multiple company projects that usually try to document everything up front rarely works out well here. Thus, there is some adoptioon of agile for these but there are still some growing pains to go through as how we use agile matures. Think installing a dozen modules of some off-the-shelf software that requires both internal and external developers to customize the suite for our specific needs as the software is supposed to be very robust, flexible and help save lots of time and money on how people otherwise do their jobs generally. Think ERP or CRM for a couple of examples here.
We are a 16-person company that creates and supports customized software for small retail shop owners.
The projects we get fall into three general categories (as related to specs):
"Here, automate this form." A sales person explains that our customer only wants this form to appear where they can fill it out and print it to make it look professional to their customer. Our specs is a single piece of paper that looks something like an order form or report. This is always false; they want pop-up lookups, automatic updating from other sources, and "while you're at it" add-ons that more than double the time. These, we've learned to just live in the moment and let the project take its course. By the time we're done, the program doesn't look anything like their original form.
Small changes. Like a simple e-mail explaining that the background color is stale, or a request to sort a report by a different column. These, we just do as time allows.
Big company integrations, where we're tasked with making our software work with some big outfit like Intuit (QuickBook) or FedEx (shipping rates). These often have well thought out documentation and sample code. We get 100's of pages in word documents or pdfs. The problem with these is when their specs are wrong. We find out about inaccuracies when we try to test or certify our integration. In these instances, we usually take longer in certification than we did to originally develop the processes.
In all cases, the real trouble is when a sales person promises a solution to the customer before even asking a programmer what it would take. As recently as 2 weeks ago, a sales person got into real trouble and had to issue a refund (that person is no longer with the company).
None - at least not from management.
Instead, as a developer (and particularly one leading a software project right now), I'm expected to contact my users/customers/etc and work directly with them to come up with our specifications and requirements. The documentation I do request from my team is only what will be useful to the team. I am lucky in that management rarely requests a document that doesn't make sense or won't provide some use to our project.
I currently have a half-dozen or so specs each 60-80 pages. One of them is 80 pages with no table of contents. Good times.
Our Product Managers and senior engineers prepare three planning docs for our data management software projects.
High-level requirements: 1-to-3 sentence descriptions of hardware/software supported or specific feature for this project. (10-15 pages of Excel-like grids)
Technical details: Engineering implementation of each high-level requirements. Up to a page for each, depending on amount of detail. (30-40 pages of filled-in feature details)
Business agreement: Summary of 1 & 2 with engineering schedule and Product Mgmt's market analysis. Everyone signs off on this. (5 pages analysis, 20 technical)
I haven't seen work flows or other Visio-like details in our specs. The prioritized requirements and schedule prove critical, so we understand when to lop things off to save development and testing time.
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).