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
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am working in 2 scrums as a developer, and it is difficult get anything done - I wanted to ask if other people have had the same issue and what did they do to manage their work?
It does not seem an agile way to work at all.
The problem is one of commitment. As a team you commit to your peers at the sprint planning meeting and each daily scrum what you will all accomplish together. If you have another team, that undermines that commitment naturally, it also inflates your WIP and causes task switching and the additional overhead of the ceremonies for two teams.
Why are you on both teams? The usual answers are: domain knowledge, skill set, because we only have one QA (insert any discipline there), funding/allocation, etc.
I fundamentally believe that your team will not have a reliable, predictable team until you form your teams in a way that you can commit to your team mates.
Report your situation as an impediment to the scrum master(s) and commit yourself only to the work you think you can achieve until this impediment is solved (by the scrum master(s)). It is not a contest on who commits to the most work done and then not achieving it.
I rather think this is a discipline issue. If you are following you need have scrum disciplines. What happens is when you are a shared resource, there will be switching cost and productivity loss. If you still want to follow this, you need to take actions to reduce switching cost and increase productivity.
One thing that you can defined dates where you are going to work on. Ex: first three days you are in one project and next two days your are in other project. If you define like that, then you can plan work to increase productivity and reduce switching cost.
Another thing is that reduce the participation time on stand ups and sprint planning. Make sure to prioritize your areas and discuss and then you leave those ceremonies than staying for the entire meeting. this is a responsibility of the scrum master to plan.
Working in multiple teams is possible, but each team needs to be considerate and accept they are only going to get 50% (or just under) of your time.
When planning, don't over commit, look at how many story points you can roughly achieve in a sprint and only commit to 50% of that total for each team.
Try splitting your time into Team A's work in the morning and Team B's in the afternoon. Each team will then know when you are available to them and should try (unless urgent) not to disturb you when you are not doing their work.
Have dedicated times for planning, standups and try to get the team to stick to these so you are not double booked.
The scrum master (or any elected person) for each team could also consider having a scrum of scrums where they get together and quickly discuss how things are going in the same way as a normal scrum so that they understand what pressures you are under.
However you mange this, you will get less actual work done than being in one team due to the commitments such as planning, standups, retrospectives which agile introduces.
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 8 years ago.
Improve this question
During the past year, our organisation has began using Scrum. Over the past few Sprints it has become apparent that our Scrum isn't really working - we have difficulties with dependencies of certain tasks, and we are way off on our burn down charts.
Historically, we'd never paid any attention to our velocity and complexity of products, and everything was pretty much a guess.
We are nearing the end of our first Sprint on our new project. I have been working over the past couple of days of ensuring that we have a prioritized, complexity estimated product backlog. I retrospectively added the user stories that we are working on in the first sprint. It's quite apparent that we have bitten off more than we can chew.
We estimated our team velocity to be 28 story points, however, we haven't actually finished any of the user stories. Is our team velocity actually zero, and if so, how do I begin trying to plan the next sprint? Do we need to re-estimate our team velocity going into Sprint 2? Or can we take a best guess of what our velocity actually is given the percentage of the user stories we've actually completed?
Another issue we have is that our team is split into three tiers - Data, UI, and Services. This can make Sprints difficult to plan because of the different skill sets. For example, we have a very large user story which involved importing data from our legacy system (almost a whole sprints worth), but only our Data guys are able to work on this story, so we need to add additional stories which will allow the UI and Services team to also be involved in the sprint. We are then stretching ourselves even further.
Not many people on the team understand Scrum that well. I did a Scrum master course about 4 years ago, and I've forgotten a lot of what I'd learned, and I'm really struggling to get this Scrum team working well.
We have a scrum team of 14. Is this too big, should we try and have two smaller scrum teams? We are all working on the same project.
I'd be very appreciative of some advice from seasoned Scrum Masters on what we can do to try and help our Scrum process.
It sounds like the retrospective for this sprint will be interesting! These are some of the things that I might try and encourage the team to focus on in the retrospective:
Your velocity is unfortunately 0 because no stories are Done. I would encourage the team to consider:
What went wrong with the unfinished stories? What stopped them getting to Done?
Were the stories too large or complex? If so, how could they have been broken down? Beware splitting the stories into "layers" - stories should be split into vertical slices so each story still delivers an increment of user value.
Did the team start too much and not focus on finishing what had already been started (too much work in progress)?
You might need to remind them that the team as a whole succeeds or fails - if one part of the team struggled it was up to the rest of the team to support them and come up with a solution.
As discussed above, stories should be vertical slices of functionality, not horizontal ones. This is tricky because software engineers often think in "layers". How can you overcome this with the "tiered" team? In particular, how can you avoid hand-offs between the three groups (hand-offs are expensive and cause delays). Some thoughts:
Could the Data team have provided a stub (e.g. an interface that returns hard-coded dummy data) to allow the UI and Services teams to proceed while the data layer is being completed?
Could a cross-functional group have swarmed on each story (so all three "tiers" are forced to work together on completion of a story)?
How can the tiers cross-train so they can take on work outside their specialist areas (this is the concept of "generalising specialists" or "specialising generalists"). This will allow them to support each other when the going gets sticky.
Is the scrum team too large (probably)?
A "two pizza" team of 5-9 members is ideal
Would it be possible to split the team into two scrums with people from all three tiers in each scrum?
Each scrum can work independently on an epic
Outside the retrospective, the scrum master and product owner might want to think about a couple of things:
Backlog management is really important (and really hard to get right) - it sounds like you have done lots of work on this, but it is vital to keep it up. A poorly groomed backlog will stall the team.
If you have silos (e.g. between the "tiers"), you need to work to break them down. Silos reduce the team's flexibility and create hand-offs which are expensive.
Finally, "Succeeding with Agile" by Mike Cohn is a really great book which covers the practical side of making scrum work in the real world. I found it extremely useful.
Bids has given good advice and what I consider the answer to the headline question but it is buried in there. I wanted to explicitly call it out:
Would it be possible to split the team into two scrums with people from all three tiers in each scrum?
In Scrum stories are intended to be vertical slices through the system. You should restructure your teams so that they have the expertise to develop the end-to-end features. This will make a huge difference and I would try this before doing any other tweaks.
Not finishing any stories is pretty bad. You should limit the amount of work in progress.
I would recommend that you give the team only one story and make them work together on it. They're obviously a brand new team, that need to learn to walk before they run.
Would this be wasteful by not fully utilizing team members? Maybe, but the team haven't proven they can actually deliver anything. At least delivering one thing would prove a certain level of productivity and it would force them to actually work as a team.
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 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.
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.)