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
Joel often talks about using MS Excel for lightweight project management, but I'm curious about actual implementations of this idea. I've seen some templates that seem to clone MS Project via macros, which would be overkill for a lightweight project. Anyone have any useful templates?
try
feature task estimated hours actual hours current %
---------- ---------- --------------- ------------ ---------
if estimated hours times current % is greater than actual hours, you are behind schedule
update the actual hours and current % on a daily basis
see also joel's old excel template
Maybe a bit off-topic, but you might want to consider testing Google Docs. There is a Gantt chart widget provided by Viewpath in the "Insert->Widget..." menu option.
You have some pretty advance template with Pipetalk Scheduler
alt text http://ep.yimg.com/ip/I/pipetalk_2055_216386
However, since it seems to be a little too much, I just transfered that to the worst UI thread ;)
Edward Tufte - aka "the man" when it comes to data representation has done a lot of work on Gantt charts (http://en.wikipedia.org/wiki/Gantt_chart) has some good information on this topic, but basically it boils down to using Excel as a Gantt chart creator, the advantage being that it's simple and won't get in your way much:
http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=000076
It's not excel, but I saw scrumy and liked it's demo. For a small project recently, I just generated a project plan using 'Cross Functional Flowchart' under Business Process with some flow/process stuff in Visio.
You could consider using a Sprint Backlog. You estimate the time for every tasks of your project and your update the estimated remaining time every day or so. Then you have a burndown chart that shows the remaining effort to complete the project.
If your project is too large for a daily tracking, you could either do the tracking every week, or manage a product backlog of the things to be done in your project as a coarse-grained level of planning and then choose the most prioritized one for the finer-grained planning level.
You might want to look at Scrum(1) or any other agile methods for lightweight development methods for further details.
(1) http://en.wikipedia.org/wiki/Scrum_(development)
If you like using spreadsheets and not getting involved with too many fancy tools, have a look at The One Page Project Manager - it's exactly as described, a nice, lightweight way to keep track of all your important project info on a single worksheet.
Much simpler: some Gantt graph in Excel ,as illustrated here.
The columns I use are
1) Task Name
2) Budget Hours
3) Total Hours
4) Remaining Hours
The Key is column (4). Rather than getting the person to estimate a percent complete; get them to re-estimate from this point forward. Its a subtle change but the mindset is much different. Otherwise you almost always end up stuck at 90% complete.
There are a lot of useful template in this page. Also, you can read more in our project management software blog.
Hope it helps :)
I use EasyProjectPlan which is an Excel Project Plan that syncs with Outlook and MSProject.
www.EasyProjectPlan.com
I use the Outlook and Calendar sync features to distribute and collect task information to my team members.
I distribute the EPP Excel file to all team members either by email or I post it in a shared folder.
My team members can edit the EPP excel file and send the changes back to me.
Most of the companies I work for have no PM task management system so EPP allows me to walk onto any project and immediately distribute and collect task information to all team members. Considering that most companies use Excel and Outlook, there is nothing to install on any computer.
In my experience, team members prefer to view task information in Excel and Outlook.
Related
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
Referring to this buddy question, I want to know how one can manage specs in Scrum process ? I'm facing this problem while assigning tasks to my team for the sprint. Needless to say - I'm new to Agile/Scrum.
Currently, we are using our own specs sheet to map StoryId to SpecId and vice versa. I'm getting the felling that Scrum is more about project management [getting things done on time] and you need a seperate process to manage specs and requirements.
How do we manage specs in a Scrum process ?
The short answer is, you don't.
The important question to ask yourself when writing these specs, is why do we do them? What is the value in the spec?
The value in the spec usually comes in communicating the ideas of the business with the development team. Scrum is designed to bring the business (in the form of the Product Owner) to the development team. By interacting with the team frequently (remember, individuals and interactions over processes and tools), and by seeing working software frequently, the business can work hand in hand with developers to produce software that solves business problems better than by trying to spec out the whole thing before you get to try it out.
This is how Agile projects do a better job of delivering the product the business wants instead of the product they requested.
That said, there are certain base criteria that need to be met. We can test for this, and as with any good tests, we can automate it.
Have a look at BDD and Cucumber. In addition to your User Story, it's good to have a basic set of conditions of satisfaction, preferably in the "Give/When/Then" format. These conditions are the minimum set of criteria for the story to be accepted as complete.
For example, "Given I am logged in, when I log out, then I am taken back to the home page".
If you're going to have acceptance criteria, you're going to want to automate it. The worst part of most specifications is they often end up out of date and collecting dust when the project is complete.
Also, you shouldn't be assigning tasks to the team. Scrum teams are self organizing and anyone should be able to grab any task they feel they can work on while respecting the priority of the stories. Swarming is a big part of the performance benefits of Scrum.
You may want to consider bringing in an outside coach to assist with your transition.
I think that the easiest way is to make the specifications a part of the user stories within the tasks, themselves. Clearly list the acceptance criteria in each one (or if your issue tracking software allows you, create them as first class work item types). Let the issue in whatever you use for work item tracking become the living document.
There are drawbacks, such as finding related issues as specs change over time, but this can usually be managed in the work item tracking tooling, assuming your can relate issues to each other.
The way that we do it is that we (actually a BA, not the developers) creates a sign-off deck for the product owner to review and we collaboratively create tasks off of that. If we cannot create a task, or there are open questions, we will go back to the product owner with those questions and update the deck. All of our decks are organized (in SharePoint) so that we can easily find them in the future.
For me the specs is in the user stories. We define the specs and the tasks duing out initial scrum meeting along with the product owner. The specs and tasks are just for the life time of the scrum iteration as everything might change in the next iteration(in the worst case but there will definitively be changes).
We usually keep track of the specifications and task on a spreadsheet just so that everybody know what they are working on. I have also tried a few software to do this and one of the most interesting ones I have come across is from [VersionOne][1] and also from [Rally][2].
But I still find that using a simple spreadsheet is the fastest and simplest solution.
As I understand SCRUM, it does not take care about specs management. You have to broke/map your specs or specs changes to stories and tasks separately. But you can have a task for this :).
There is a real tension between Scrum and other agile dev methodologies and spec writing. I think there are two big points of tension:
Because agile says everything should
be on an index card, that means you
have to have stuff planned out
enough to fit on an index card.
(E.g. you have to know how it's all
going to work.)
Some things don't make sense in
isolation (what's the use of an
upload file page without a manage
uploaded files page, for instance.)
You don't have to design the whole app all at once, but you have to have a vision of the whole app. Then, especially if you have a separation of designers and programmers, you do functional design for a sprint-sized chunk at a time. Those designs then have to be broken down to story-sized chunks.
This is a lot of up front functional design, and I think that's overlooked in a lot of the talk about agile methodologies. Perhaps some shops have the devs do more of the design. Also, I think it's a lot easier to use scrum/agile for making changes/bug fixes to existing apps rather than building new ones.
The thing I've found most helpful is to fight back on story size. A lot of organizations have gone crazy, saying stories need to be only a few hours. The original scrum book says 16 hours, I think, which is often large enough to fit an entire screen of a web app. So "implement manage my account" could be a story (as opposed to the hundreds-of-tiny-stories approach of "implement username", "implement password" etc.) Then reference your design doc for "Manage My Account" and make sure to have word-perfect screenshots/prototype/mockup so the dev can look at them and copy/paste the text directly into the code they're writing, and they know for sure which fields need to be there (or which links, or which pictures, or whatever).
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 7 years ago.
Improve this question
I have been thinking about setting up some sort of library for all our internally developed software at my organisation. I would like collect any ideas the good SO folk may have on this topic.
I figure, what is the point in instilling into developers the benefits of writing reusable code, if on the next project the first thing developers do is file -> new due to a lack of knowledge of what code is already out there to be reused.
As an added benefit, I think that just by having a library like this would encourage developers to think more in terms of reusability when writing code
I would like to keep this library as simple as possible, perhaps my only two requirements being:
Search facility
Usable for many types of components: assemblies, web services, etc
I see the basic information required on each asset/component to be:
Name & version
Description / purpose
Dependencies
Would you record any more information?
What would be the best platform for this i.e., wiki, forum, etc?
What would make a software library like this successful vs unsuccessful?
All ideas are greatly appreciated.
Thanks
Edit:
Found these similar questions after posting:
How do you ensure code is reused correctly?
How do you foster the use of shared components in your organization?
Sounds like there is no central repository of code available at your organization. Depending on what you do this could be because of compatmentalization of the knowledge due to security restrictions, the fact that external vendor code is included in some/all of the solutions, or your company has not yet seen the benefits of getting people to reuse, refactor, and evangelize the benefits of such a repository.
The common attributes of solutions I have seen work at mutiple corporations are a multi pronged approach.
Buy in at some level from the management. Usually it's a CTO/CIO that the idea resonates with and they claim it's a good thing and don't give any money to fund it but they won't sand in your way if they are aware that someone is going to champion the idea before they start soliciting code and consolidating it somewhere.
Some list of projects and the collateral available in english. Seen this on wikis, on sharepoint lists, in text files within a source repository. All of them share the common attribute of some sort of front end search server that allows full text over the description of a solution.
Some common share or repository for the binaries and / or code. Oftentimes a large org has different authentication/authorization methods for many different environments and it might not be practical (or possible logistically) to share a single soure repository - don't get hung up on that aspect - just try to get it to the point that there is a well known share/directory/repository that works for your org.
Always make sure there is someone listed as a contact - no one ever takes code and runs it in production without at lest talking to the previous owner of it - and if you don't have a person they can start asking questions of right away then they might just go ahead and hit file->new.
Unsuccessful attributes I've seen?
N submissions per engineer per time period = lots of crap starts making it's way in
No method of rating / feedback. If there is no means to favorite/rate/give some indicator that allows the cream to rise to the top you don't go back to search it often because you weren't able to benefit from everyone else's slogging through the code that wasn't really very good.
Lack of feedback/email link that contacts the author with questions directly into their email.
lack of ability to categorize organically. Every time there is some super rigid hierarchy or category list that was predetermined everything ends up in "other". If you use tags or similar you can avoid it.
Requirement of some design document to accompany it that is of a rigid format the code isn't accepted - no one can ever agree on the "centralized" format of a design doc and no one ever submits when this is required.
Just my thinking.
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
We are trying to implement SCRUM with the Microsoft SharePoint Online. Although we can use tasks and issue tracker to suit SPRINTS and iterations and system testing, we are using an excel speadsheet to produce the burndown chart. However, we have to extract all the tasks first, reformat the data, the feed in the chart values. Does anyone have a quicker way?
We use SharePoint custom lists to help us implement scrum. It's far from perfect, but allows for a lot of flexibility.
What we do is extend the tasks list to include a sprint number (really a lookup to another list), product backlog (another lookup), estimated effort, and estimated time to complete columns (ETC-01 through ETC-10 - we do one or two week sprints). We also have a field to flag whether the row is capacity data or not (one of these rows per sprint per person).
Then we have several views, but one primary view which shows a grouping by "is capacity data" followed by "assigned to". We also total those ETC values. So our summary view can give us a quick look at the total for the team for both capacity and estimated time to complete for any day in the sprint. We currently manually put this in Excel, but have considered automation as well. We have another view that is a datasheet view used for data entry. Almost all of our views have a master-child page where you choose the sprint master to view the sprint backlog details.
So, all of that sounds rough, but it's pretty easy to use once you get the hang of it.
The benefit is that we have a lot of flexibility when we need it. For example, our Product Backlog list may have custom columns depending on the project.
We have used 3rd party tools before, but for us it gets a little difficult because we are a consulting company and our clients interact with these tools as well.
G'day,
I can't really comment on the SharePoint aspects as I'm a *nix guy. I thought I'd mention that you should be referring to it as Scrum. It's not an acronym but taken from a word that refers to a part of the game of rugby where everyone binds together and each team member has a particular job to do. So the convention is to refer to it as Scrum.
There are lots of excellent, free tools out there to assist with sorting out your burndown charts rather than just chewing raw Excel data.
BTW Good luck with the SharePoint bits. (-:
Edit: Actually, while looking for a couple of tools I stumbled across the 21 Apps site which specialises in Agile SharePoint solutions. Some interesting looking stuff there.
If you are not constrained by Sharepoint, there are plenty of free and locally installable tools that would simplify your life a great deal.
Example: http://github.com/friflaj/ajellito
Apologies for the blatent plug - we found the same problem with not having a great user experience of doing Scrum in SharePoint - lists are good but nothing really gave the easy to use as a whiteboard experience.
I have used other tools like VersionOne - but really find that add to many features and just get over complicated for most teams to get into.
We create a Scrum for SharePoint solution: 21Scrum
Note: This is only availble for SharePoint 2010 as we have built it to work in the Sandbox for easy deployment.
Andrew
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
Quite often I would complete numerous daily tasks i.e. not working on anything one component in particular. Therefore, I find it quite difficult to remember these individual tasks in our next day stand up meeting. Is it ok to bring a small sticky note with a few reminder points on the previous days tasks? For example, the contents of the sticky could be:
Yesterday:
----------------
- Implemented component X
- Refactored Y class
- Updated Bamboo build settings
- Submit test request to 3rd party harness
- Read up on X API
Today:
----------
- Write tests for component B
- Implement component B
- Document install instructions
- Code review meeting
Obstacles:
----------------
- Sys admin still haven't opened external port
What are your views on this?
A key point of scrum is that it's not written in stone -- you should adapt it to whatever works best in your organization. However, the daily standup meeting is meant to be short, so if you bring notes, you should use them as a reference, not like a meeting agenda.
Yes, short notes are fine. Long stories probably destroys the relationship with your coworkers.
Implement Scrum in a way you feel it comfortably. Stand up meetings should be short, but who is saying that they can't take so much time as you need it?
If you are using some kind of Scrum tool, you don't have to take your notes, all is written in tool - obstacles, tasks status, comments.
I don't know if it is "officially" ok but I do this all the time. If you are like me and lose track of the last thing you did because you are now focusing on something new then write stuff down. Its better to show up at SCRUM with a short list then to show up and say: "now ... what was it I was working on?".
I think notes are ok, but you are talking about subjects which may not be pertinent to user stories in your sprint. If you keep focused on that rather than other tasks that you have performed you will keep the scrum meeting short and relevant.
If the tasks are relevant say what story they were part of to give co workers context.
I don't see any reason why it wouldn't be OK to bring some notes to the daily meeting.
In our team, we have extended the daily scrum a little bit. It consists of the following parts:
The normal daily scrum (yesterday, today, obstacles). This should not take more than 5-10 minutes.
We update the sprint backlog. Should not take more than 5 minutes. This ensures that the whole team knows about the the current state of the sprint backlog.
If required, we discuss any important topics (which concern the whole team)
If required, we schedule meetings between team members (or directly hold the meetings after the daily scrum).
Because of the way we do the daily scrum/daily meeting, it is quite normal that everyone brings some short notes, for example about what topics they need to discuss with others.
After all (as others already mentioned), you should implement SCRUM in a way that works for you and your team. And of course you should always be open to improve/change your process if you found some problems (e.g. during a retrospective).
Why would they not be?
Only rules are:
Answer the three question
what did you do yesterday
what are you going to do today
what is blocking you
you speak to the team (not any one individual)
you keep it short
no story telling
no problem solving
speak when you have the token
know who to send the token to next (not someone that has already spoken)
if someone goes long or tries to problem solve others may call for a focus meeting after the stand up
Story card wall should be visible
A person in the room updates the blocker boards as blockers are called out
Notes are fine, as are projectors, laser pointers and beanie caps with propellers.
The answer to the basic question is yes. It is entirely appropriate to bring notes to a standup if it helps you.
Your example, however, points to a common pitfall in standups... providing detail on activities that may not be important to the team. You read something, and you attended a meeting. Those are examples of what I sometimes refer to as "justifying your 8-hours".
The key is - share what you did and what you will do without elaboration. If someone has questions on something particular, they can ask for details outside the meeting.
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 5 years ago.
Improve this question
"Evidence-based scheduling" in FogBugz is interesting, but how do I use it w/ an Agile methodology?
As eed3si9n said, if you are consistent in your estimates for EBS, FogBugz will take care of this for you.
As to the more general, how does FogBugz fit with the Agile methodology, your best bet is to do sprints as mini-releases. Create a sprint and add the cases you want to achieve for that sprint to that release (or milestone). Give it an end date, say a week away, if you do week long sprints. Then EBS can track it and tell you if you are on schedule.
The graphs in the Reports section will also show you a burndown chart. The terminology is a bit different because FogBugz isn't Agile-only but the info is there.
You want to see if the expected time you are going to finish your sprint is staying steady or going forward. If it is steady you are on track and your burndown rate is on target. If it is creeping up, you are losing ground and your sprint is getting delayed. Time to move things to the next sprint or figure out why you messed up your estimates :)
Essentially I suppose this is a burn-up chart instead of a burndown chart, but it gives you the same answer to the same question. Am I going to finish on time? What do I have left to do?
Atalasoft's Lou Franco wrote an excellent post on this as well. Patrick Altman also has an article.
Update: fixed link to Altman's article
I asked the FogBugz guys the same thing because in XP for example you'd provide the estimate in IET (ideal engineering time). Their answer was to be consistent in the way you provide the estimate.
We started using FogBugz for pretty much everything within our technical team: Documentation, bug reporting, managing tasks. We have progressively got more Agile as time has gone on.
What I have done is created a release which is called the Product Backlog, and this is given an arbitrary release date in the future. I changed the FogBugz field "Version" to "Priority" so we can sort by priority. To manage the product backlog I heavily use Areas to categorise the user stories. Areas could be Themes or Epics. Each Iteration is a Release in FogBugz.
Now, one thing we have recently started using is Story Points as opposed to Ideal Task Days for estimating our Product Backlog. FogBugz doesn't understand a unit of measurement of Story Points so rather confusingly, 1 SP in our Product Backlog is reported as 1 Day in FogBugz. This could be dangerous if there is any confusion. But our team is small. I don't use the in built reporting tools in FogBugz, but it would be great if I could.
So, all my Story Point and Velocity calculations are done outside of FogBugz in Excel. This seems to be fine for now. We're tracking tasks using index cards for user stories and post-it notes as tasks on our boards in the office. Have a look at the book "Scrum and XP from the Trenches" book by Kniberg which influenced my decision. Actually having a big board with everything on it which we are staring at in our morning Scrums really helps.
I do think the historical estimation history and reporting in FogBugz is excellent. Does this work with the planning poker world? I suppose at least from a team's estimation history it does.
As User Stories in the Product Backlog often evolve as there are iterative planning sessions, (Agile Planning) it would be great if there was a wiki style editing of cases as opposed to a thread of descriptions.
There is talk that the next major version will be more supportive of Agile processes so am very much looking forward to seeing that this offers.
Edit:
FogBugz 7 is now out with much better management of Product "Project" Backlogs. Take a look!
http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features.aspx
Here are some suggestions for including Story Points in your planning:
When you enter your Story into FB7 you can do it as a Case and include the number of Story Points from Planning Poker in a new custom field that you create called "Story Points" (how to do this below). Then, when you get around to working on that Story, you can break it down further into Sub-Cases, if necessary, and also enter the estimated time to complete each Sub-Case (the estimated times will add up in the Story (top) Case's "Estimate" field, as well as feed Evidence Based Scheduling / Burndown Charts)
Here are two things to consider modifying in your FogBugz installation to reflect your Agile nomenclature.
(1) Out of the box, the FB Category "Feature" is most like your "Story." But you can change your Category names, and add new ones at Admin > Workflow > Customize Categories. Here's additional information on this:
http://www.fogcreek.com/FogBugz/docs/70/topics/plugins/CustomWorkflow.html?isl=174457
(2) To capture Story Points, you'll probably want to create a Custom Field in the Case dialogue. This is accomplished with the included Custom Fields Plugin. Additional information on this is available at isl=174461
Note that with Custom Fields, you can also add a text edit box for the Story which will always appear in the Case dialogue header (no matter how lengthy the case activity history below it gets.)