2

My company is slowly adopting Scrum and I am doing my best to try to push us away from old Waterfall paradigms. However there are certain aspects I am finding quite hard to map in Team Foundation Server (TFS - visualstudio.com).

The challenges I have at the moment are as follows. I am quite new to Scrum so any advice/critique is highly appreciated:

  • Investors require dates of high level estimates for certain milestones. For example, when should we expect a MVP (minimum viable product) to be ready. However, only tasks can be measured in hours. How can I provide the investors with a good set of proposed milestone dates in this case?
  • I was told that Ideally, we should NOT use EPICS to represent a release. But since I see no other viable way of achieving this in TFS, I created an Epic called 'Minimum Viable Product' and added the features we want there. Thoughts?
  • Finally, I got contradicting opinions on whether operational aspects of the product development should be included in TFS or not. Things such as 'decide on framework', 'set-up development environment', etc. One Scrum Master tells me we should NOT do this because Scrum should only list product deliverable, while the other told me told me that it is obvious that these things should be there as we need to account them in the product development.

Here is a screenshot of my backlog at this point: My TFS backlog at this point

Improve this question
1

Investors require dates of high level estimates for certain milestones.

This isn't really in the spirit of Scrum... more Waterfall. Still, it's not like you can just say "Sorry, investors, no initial estimate for you', so. What's often done is you do an initial estimate of all the known stories needed for the minimum viable product (MVP), then using your established velocity (which you probably don't have, if you're just starting out with Scrum), you calculate the time needed to complete all the work. If possible, have your investors understand that this is just an initial, rough estimate, and it will be adjusted when more information becomes available. Also if possible, give a range of values.

I was told that Ideally, we should NOT use EPICS to represent a release.

There's nothing in the Scrum Guide about Epics or the lack thereof, so just do whatever makes the most sense for your team. Don't let a tool or a convention constrain you or your Team.

Finally, I got contradicting opinions on whether operational aspects of the product development should be included in TFS or not.

If CodeGnome will forgive me purloining his Law...

"No invisible work, ever!" — CodeGnome's Law of Transparency

You should be keeping track of these developer tasks. However, if possible, you should differentiate somehow between these developer tasks and normal, business-related Stories. Since, after all, people outside the Development Team should be able to see the Scrum Board, but wouldn't care about these tasks.

Improve this answer
  • Thank you so much for your input, Sarov. Everything you said makes sense. My only issue now is how to adopt some of what you said in TFS. I was hoping that some could share their thoughts with me. For instance, the best way of separating the 'infrastructure' or 'business as usual' tasks from the actual product deliverables. – pmdci Jul 24 '17 at 13:46
  • It's been years and years since I've used TFS, so I can't give any in-depth-tech answer to that, but if all else fails, you can just add something like "(DevTask) " to the start of the Story name. – Sarov Jul 24 '17 at 16:16
2
  • Investors require dates high level estimates for certain milestones. For example, when should we expect a MVP (minimum viable product) to be ready.

It might be too early to say ... are you the scrum master ? This is really a question for the PO. But at the end of the day, until some sprints are under you r belt you can't give any realistic estimates. See @WoodyZuill's twitter account to get details of the #NoEstimates movement.

  • Ideally, we should use EPICS to represent a release. But since I see no other viable way of achieving this in TFS, I created an Epic called 'Minimum Viable Product' and added the features we want there. Thoughts?

A release may include many eics or pieces of many epics ... so you re trying to balance MVP with continious delivery. The better option for your investors would be ... how do we increment what we have to be something more valuable? And thus take a shorter view of the project. its waterfall thinking to say, you'll be live with your MVP in 6 months. Its an agile view to say, in 6 months time your product will be a better product with (hopefully) many smaller increments of functionality.

  • Finally, I got contradicting opinions on whether operational aspects of the product development should be included in TFS or not. Things such as 'decide on framework', 'set-up development environment', etc. One scrum master tells me we should NOT do this because SCRUM should only list product deliverable, while the other told me told me that it is obvious that these things should be there as we need to account them in the product development.

As these are not going to be delivered to live the No is the correct answer. there is a clue in some of the task names e.g. "Discuss" & "Evaluate"

Improve this answer
  • Thanks for pitching in. # To answer some your question, I guess I am the Scrum Master (even though I don't have the certification). I reckon you are right about having some sprints under the belt. I was told the same by two people. # I meant to say that I was told that ideally a release should NOT be represented as an epic. But then I don't know how to represent releases in TFS. # As for the non-deliverable features like 'discuss' and 'evaluate', how can I account for the time of those if I don't have them in a sprint? It is still work that must be done! :) – pmdci Jul 24 '17 at 12:21
  • A release in TFS (in an ideal world) is a single sprint. However however many companies have established release planning that is less frequent than a 2/4 week sprint. So it would be fair to say a release is one or more sprints. – Andy L Jul 25 '17 at 13:52
  • For the non deliverable pieces ... they can be represented as a spike ... i.e. a piece of learning that needs to be done to enable a user story to be completed. In your given example, our architects and dev ops teams would answer most of your tasks that you give in the above example, rather than the dev team. Our Architects would run their board seperately – Andy L Jul 25 '17 at 13:55
  • If your set up includes architecture as part of your scrum team, you might find that they are attributes of the development stories. i.e. developing a new piece of functionality my require a decision to determine if its a Server or Client task. – Andy L Jul 25 '17 at 14:02
2

I like @sarov's answer, and just wanted to add some TFS related bumph in realted to the Scrum bumph, maybe with a little extra Scrum bumph.

Investors require dates of high level estimates for certain milestones. For example, when should we expect a MVP (minimum viable product) to be ready. However, only tasks can be measured in hours. How can I provide the investors with a good set of proposed milestone dates in this case?

(scrum theory) This is something that is totally within the purview of the Product Owner and does not belong in TFS. TFS is an effort tracking system rather than a time tracking system.

(scrum practice) If you are planning in Scrum then one good practice is to have your Development Team estimate each of your backlog items in relative sizes based on numerical points. While your Development Team can use those point to help them decide how much work to forecast for the next Sprint, your Product Owner can use them to forecast multiple Sprints and when some of their milestones might be hit.

(tfs/vsts) I would try to get your Product Owner some training in how to monitor value. There are good training courses from both Scrum.org and the Scrum Alliance. If you are using VSTS (cloud TFS) then you get the Delivery Plan (https://marketplace.visualstudio.com/items?itemName=ms.vss-plans) extension that will allow you to easily and visually plan for future sprints, but its still not about hours.

(scrum theory) Ultimately if anyone is giving guarantees to your investors then you are not respecting them. It is fundamentally imposible to determine up front how long a backlog item will take to deliver and when it will be available. Make sure that you focus on forecasts, not exatimates.

I was told that Ideally, we should NOT use EPICS to represent a release. But since I see no other viable way of achieving this in TFS, I created an Epic called 'Minimum Viable Product' and added the features we want there. Thoughts?

(scrum theory) The Scrum guide does not talk about Epics or Features because they are all just Backlog Items...

(scrum practice) There are many ways to organise your work and it is up to you how. However a common practice is that Epics, Features, and Backlog Items all represent the same thing just with varying degrees of granularity. Since they are all in the execution flow they all need to represent the value delivered to the customer.

(tfs/vsts) There are no hard rules here, however TFS has an out-of-the-box method for managing time based predictions. You will already have Sprints in the Area Path and since it is hierarchical you can add many levels. A common method is:

\Release 1\
\Release 1\Sprint 1
\Release 1\Sprint 2
\Release 1\Sprint 3
\Release 1\Sprint 4 
\Release 2\
\Release 2\Sprint 5
\Release 2\Sprint 6
\Release 2\Sprint 7

Since you can point "Teams" at a particular set of paths you can create an additional team and point it at Releases, giving your Product Owner a high level planning feature. I created a pretty detailed post on how to configure it: https://nkdagility.com/creating-nested-teams-visual-studio-alm/

Finally, I got contradicting opinions on whether operational aspects of the product development should be included in TFS or not. Things such as 'decide on framework', 'set-up development environment', etc. One Scrum Master tells me we should NOT do this because Scrum should only list product deliverable, while the other told me told me that it is obvious that these things should be there as we need to account them in the product development.

(scrum theory) Your Product Owner is accountable for the Product Backlog, its contents, and everyone's understanding of it. With that in mind it may, or may not make sense to have these items in the Backlog depending on your Team, your Product, or your company.

(scrum practice) Many Scrum Teams will put clearly marked 'architectural' or 'infrastructure' items into the Product Backlog to make sure that things are not forgotten. [this practice comes from SAFe]

(tfs/vsts) From TFS 2015 there is an additional field on every execution work item (Epic, Feature, & Backlog Item) that is a dropdown list with the values of "Business" and "Architectural".

(scrum practice) A conflicting good practice is to never put anything that your stakeholders would not understand in the Product Backlog.

(warning) Whatever you choose make sure that you can transparently represent technical debt transparently.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.